After doing some more reading in specs and mailing list archive I think this is what I have to implement in the B2BUA. Not as simple as I would like but doing it this way I think would follow 3264 and 3261 and therefore should be ok with all UAs following the same specs.
* A sends Invite with asdp to B2BUA * B2BUA forks the call to B, C and D * C sends 183 (unreliable) with csdp to B2BUA * B2BUA sends 183 (unreliable) with csdp to A * A receives the 183 and sets up early media to C * D sends 183 (unreliable) with dsdp to B2BUA * B2BUA sends a empty 183 to A (since in the spec it doesnt say what A should do if it receives a new answer in the same offer/answer dialog). One option would be to send the 183 but add csdp in it. * B sends 180 to B2BUA, B2BUA forwards the 180 to A * B sends 200 OK with bsdp to B2BUA * B2BUA sends CANCEL to C and D * B2BUA sends 200 OK with csdp to A (B2BUA must sends sdp in 200 OK since it cant be sure if A did receive the 183 with csdp and according to 3261 13.2.1 it must send "the same exact answer" in provisional and final responses) * B2BUA sends empty reInvite to A and gets 200 OK with a'sdp as a response * B2BUA sends reInvite with a'sdp to B, gets 200 OK with b'spd as a response * B2BUA sends ACK to B and ACK with b'sdp to A Of course, if most UAs would treat all incoming answers as a new answer and would use that instead my scenario would have been much simpler, the B2BUA would just have to forward all responses from B, C and D and would not have to worry about any SDP. After reading the archive it looks like it is not safe to make that assumption. If 183 is sent reliable, well... I guess I could do the same as above to be on the safe side. Maybe I have to only send csdp once and then in the following 183s send them empty. But then maybe thats not fair to D in my example above where D sends a 183 reliable conatining SDP and would get a PRACK so it should of course assume that A has got dsdp (which the B2BUA removed before sending to A) Regards, // Andreas > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Andreas Byström > Sent: Friday, September 14, 2007 8:49 AM > To: 'Paul Kyzivat'; [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Sip-implementors] Early media and forking calls > > > Thanks Bala and Paul, > > I have looked for this issue in the latest months in the > archive but didnt find anything about it (I will dig deeper > to see earlier queries in this matter). > > I can understand that A will get two sessions (one to A and > one to B). Now to spice up the case a bit I will change the > proxy to a B2BUA (which I'm responsible over). Im very sorry > that it was not clear in the first mail, basicly I was just > looking for a scenario and it was not until I saw your answer > that I understood that B2BUA or proxy makes a big differnece > in this case > > So... > * A sends invite to B2BUA > * B2B forks the call to B and C > * B answers with 183 with SDP > * C sends 180 with no SDP > * C sends 200 OK with SDP > (* B2BUA cancel call to C) > > Now A has only one session, and that session is with B2BUA. > What A does with the SDP(bsdp) sent from B2BUA to A in a 200 > OK I have to read about in 3264 but if I remember correctly > it will just ignore it (will do some reading and get back if > I find some other actions). Maybe it does also matter if the > SDP is in a reliable provisinal response or not? Anyway, my > guess is that B2BUA needs, when it gets 200 OK from B: > - send first the 200 OK (with bsdp) to A > - Send a empty reInvite to A > - get 200 OK with a'sdp > - send reInvite to B with a'sdp > - get 200 OK from B with b'sdp > - send ACK to B > - send ACK to A with b' sdp > > That will do the trick, will it? Maybe it is also possible to > use UPDATE in some way > > // Andreas > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Paul Kyzivat > > Sent: Thursday, September 13, 2007 8:26 PM > > To: [EMAIL PROTECTED] > > Cc: 'Andreas Byström'; [email protected] > > Subject: Re: [Sip-implementors] Early media and forking calls > > > > > > When you get the 200 from C you can assume that the proxy > > sent a CANCEL > > to B. But you cannot assume the CANCEL will work. It is still > > possible > > to receive a 200 from B. You need to be prepared to handle > that case > > too. (The usual thing to do is send a BYE on the dialog of any > > subsequent 200 responses.) > > > > Paul > > > > Bala Neelakantan wrote: > > >> -----Original Message----- > > >> From: [EMAIL PROTECTED] [mailto:sip- > > >> [EMAIL PROTECTED] On Behalf Of Andreas > > >> Byström > > >> Sent: Thursday, September 13, 2007 9:48 AM > > >> To: [email protected] > > >> Subject: [Sip-implementors] Early media and forking calls > > >> > > >> Hi everyone, > > >> > > >> I'm working with a case that involves a call from A that a proxy > > >> forks to B and C. I see a potential problem when the following > > >> happens: > > >> * A sends SDP offer > > >> <proxy forks the call to B and C> > > >> * B answers with a 183 including a sdp answer > > > > > > Please refer to RFC 3264 as it describes the offer/answer > > scenarios. > > > Also this issue has been discussed in the Sip-implementors list a > > > number of times, and you will learn a lot by reading through them. > > > > > > So, 183 from B will create a dialog. > > > > > >> * C sends 180 with no spd > > > > > > This 180 response is another dialog and A should be > > prepared to handle > > > this dialog. At this point, the final response (200 OK) could be > > > coming from B or C. > > > > > >> * C answers the call first, which means C sends a sdp > > response in the > > >> 200 OK. > > >> > > > > > > In this scenario, the call is established between A and C. > > Typically > > > the proxy will CANCEL the forked call to B. > > > > > >> I have tried to find info on this but have failed to do > > so. So I was > > >> thinking that someone on this forum have already been facing a > > >> scenario like this, or maybe know where I can find info > on how to > > >> solve it in a way that dont violate specs (and also works > > of course) > > >> > > > > > > Please refer to the mailing list archives. > > > > > >> How should A handle this (it already got a sdp answer on > > the offer)? > > >> Does A or proxy have to start a renegotiation with C? > > > > > > I think your question is how should A handle the answer > it received > > > already from B? The proxy CANCELs the call to B. > > > > > > When the C comes back with 200 OK with SDP, that is going > > to be used. > > > > > >> Should A see in the tag that this is a respone from > > another UA then > > >> from where it did get the first spd answer (the on in 183 > > sent from > > >> B) and therefore accept it? > > > > > > That could be bad implementation choice. > > > > > >> Proxy needs to send a cancel to B when it sees that C is replying > > >> wiht 200 OK. Does the proxy also need to say something to A to > > >> terminate the media session already set up between A and B? > > > > > > Proxy doesnt tell anything about media/SDP. It is between > > endpoints. > > > > > > > > >> Thanks in advance > > >> // Andreas > > > > > > Thanks, > > > Neel. > > > > > >> _______________________________ > > >> > > >> Andreas Byström > > >> Software Engineer > > >> > > >> Teligent AB > > >> Konsul Jonssons väg 17 > > >> P.O. Box 213 > > >> SE 14923 Nynäshamn > > >> > > >> mail: [EMAIL PROTECTED] > > >> web: www.teligent.se <http://www.teligent.se/> > > >> phone: +46 (0)8 4101 7221 > > >> mobile: +46 (0)733 1172 21 > > >> fax: +46 (0)8 520 193 36 > > >> _______________________________ > > >> > > >> _______________________________________________ > > >> Sip-implementors mailing list > > [email protected] > > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > > _______________________________________________ > > > Sip-implementors mailing list > [email protected] > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > _______________________________________________ > > Sip-implementors mailing list [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > _______________________________________________ > Sip-implementors mailing list [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
