[SIPForum-discussion] How should B2BUA maintain the SDP.

Sat Feb 18 17:26:39 UTC 2012

Thank you, Hemant,

B2B in my case is ,actually, true softswitch, and all originator and
terminator are subscribers. In our implementation some subscribers supply
the ringback tone to the originator (let's not discuss if it is correctly to
do). 
Your description is very helpful, but we cannot change the B2B logic and I
still need to clear one point:  if after the 2nd INVITE the terminator
replies with 180/183 (no SDP) - how should B2B act? For sure it should send
180/183 in backward direction, indicating the call progress to the
ORIGINATOR. In our current implementation B2B does send 180/183 to the
ORIGINATOR, but uses wrong SDP (despite the SDP is not included into the
180/183 from the TERM). I'd like to be sure that from the STANDARD point of
view B2B has to pass 180/183 as is (specifically for that case - without the
SDP). Am I right?
________________________________________ 
Thank you in advance,
Pavel Gavronsky

From: Hemant Kumar [mailto:uniqhemant at gmail.com] 
Sent: Saturday, February 18, 2012 4:46 PM
To: Pavel Gavronsky
Cc: Keyur Amin; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] How should B2BUA maintain the SDP.

Hi,

I feel it depends on the exact usecase you are looking for. I am not sure,
but I am just making a wild guess(ignore if it does not match with your
usecase. Sorry to modify the name of parties involved) -

1. A calls B through B2B.
2. B2B redirects the call to media server to play ringback(in early media).
3. Once some timer expires @B2B, it terminates the dialog towards media
server and ringback stops.
4. B2B initiates one more call leg towards B but B does not answer so B2B
terminates that leg also.
5. Now B2B initiates one more call leg towards C (I think again media server
to play some music).

If atleast first 2 steps are correct then 180/183 received from media
server(TERM1 in your case) must be forwarded to A otherwise ringback tone
can not be played.

As 180 ringing from B(TERM2) does not have any SDP then B2B can simply
ignore it and there is no need to forward it to A.

But with this, the following in your scenario will not work - 
  >> B2BUA -> INVITE (to:TERM3, SDP=ORIG) (According to its internal logic
B2BUA makes new call to TERM3)
  >> 180 Ringing (SDP=TERM3) <- B2BUA <- 180 Ringing (SDP=TERM3) (Here the
B2BUA correctly passes the SDP=TERM3)

as towards A, SDP offer-answer is already done. So once the call is
terminated with B(TERM2), I suggest to do following changes in your flow  - 

 B2BUA -> INVITE (to:TERM3, no SDP)
 B2BUA <- 180 Ringing (SDP=TERM3) (A new SDP offer)
 UPDATE (to: ORIG, SDP=TERM3) <- B2BUA (Send Update to ORIG as a new SDP
offer)
 200 OK(SDP=ORIG) -> B2BUA (Receive ORIG's SDP in 200 for UPDATE)
 B2BUA --> PRACK(to: TERM3, SDP=ORIG) (Send ORIG's SDP answer to TERM3 in
PRACK)

Regards,
Hemant
On Wed, Feb 15, 2012 at 1:49 PM, Pavel Gavronsky <kamm555 at hotmail.com>
wrote:
Thank you, Keyur,

The reason for the SDP in our 180/183 from the TERMINATOR is to provide the
RingBack tone from the remote party (early media).
For the case when the TERMINATOR doesn't send the SDP in its 180/183, should
the B2BUA use the "remembered" SDP value from the previous TERMINATOR leg or
just pass the 180/183 (without SDP) unchanged to the ORIGINATOR?

________________________________________ 
Thank you in advance,
Pavel Gavronsky

From: Keyur Amin [mailto:fossil0681 at yahoo.com] 
Sent: Tuesday, February 14, 2012 6:18 PM
To: Pavel Gavronsky; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] How should B2BUA maintain the SDP.

SDP is required for the B2BUA from the terminator. It it doesnt get it
180/183, it must in 200 OK. The old SDP wont work because its a different
end point. Unless the terminator is sending 183, you dont need SDP for 180. 

Thanks,
Keyur Amin
  _____  

  _____  

From: Pavel Gavronsky <kamm555 at hotmail.com>
To: discussion at sipforum.org 
Sent: Monday, February 13, 2012 6:22 AM
Subject: [SIPForum-discussion] How should B2BUA maintain the SDP.

Hello, everyone,

Setup:

B2BUA - tandem SIP softswitch (tandem between softswitch_1 and softswitch_2)
ORIGINATOR: Subscriber connected to softswitch_1 
TERMINATOR1: Subscriber connected to softswitch_1
TERMINATOR2: Subscriber connected to softswitch_2
TERMINATOR3: Subscriber connected to softswitch_1

Scenario (only important messages shown):
Call comes from the ORIGINATOR and is routed to TERMINATOR1:

INVITE (to:TERM1, SDP=ORIG) -> B2BUA -> INVITE (to: TERM1, SDP=ORIG)
100 trying <- B2BUA <- 100 Trying
180 Ringing (SDP=TERM1) <- B2BUA <- 180 Ringing (SDP=TERM1)
_____________B2BUA -> Cancel (According to its internal logic B2BUA releases
the TERM1 leg in order to make new call to TERM2)
_____________B2BUA -> INVITE (to:TERM2, SDP=ORIG) (According to its internal
logic B2BUA makes new call to TERM2)
_____________B2BUA <- 100 Trying
180 Ringing (SDP=TERM1) <- B2BUA <- 180 Ringing (no SDP) ( ??? Is it
correctly to provide the old SDP=TERM1 toward the ORIG in that case ???)
_____________B2BUA -> Cancel (According to its internal logic B2BUA releases
the TERM2 leg in order to make new call to TERM3)
_____________B2BUA -> INVITE (to:TERM3, SDP=ORIG) (According to its internal
logic B2BUA makes new call to TERM3)
_____________B2BUA <- 100 Trying
180 Ringing (SDP=TERM3) <- B2BUA <- 180 Ringing (SDP=TERM3) (Here the B2BUA
correctly passes the SDP=TERM3)

Question:
If the 180/183 from the TERM leg does not include the SDP, should the B2BUA
use the "remembered" old SDP value for the 180/183 toward ORIG leg? 

________________________________________ 
Thank you in advance,
Pavel Gavronsky

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit
http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit
http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org

-- 
- Hemant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20120218/a6c14b59/attachment-0002.html>