Re: [Sip-implementors] Offer/answer model in early media with forking

On Mon, Jul 16, 2018 at 11:01:30PM -0400, Dale R. Worley wrote: > > Well, the first branch is disposed of with a 5xx reply. But the UAC > > cancels nothing, in spite of getting two different early responses > > from two different dialogs. > > You should have mentioned the 5xx reply in your

Re: [Sip-implementors] Offer/answer model in early media with forking

Alex Balashov writes: > Due to the way the RTP relay works on the server side, this results in > two different SDP offers from the two respective outgoing branches being > sent back to the caller: > > 1. 183+SDP on branch #1. > > 2. 183+SDP' on branch #2. >200 OK+SDP' on branch #2. > > I am

Re: [Sip-implementors] Offer/answer model in early media with forking

Well, the first branch is disposed of with a 5xx reply. But the UAC cancels nothing, in spite of getting two different early responses from two different dialogs. Granted, I haven't tried waiting around for 3 minutes or whatever the maximum prescribed early/alerting state is. On July 16,

Re: [Sip-implementors] Offer/answer model in early media with forking

It should be noted that the UA with which I am testing (Freeswitch) does not CANCEL or otherwise hang up the first dialog. On Mon, Jul 16, 2018 at 01:56:34PM -0400, Alex Balashov wrote: > Oh, yes — they're different dialogs, for sure. I just wasn't sure if > that would nevertheless pose a

Re: [Sip-implementors] Offer/answer model in early media with forking

Oh, yes — they're different dialogs, for sure. I just wasn't sure if that would nevertheless pose a problem for some low-budget UAs. On Mon, Jul 16, 2018 at 01:47:32PM -0400, Paul Kyzivat wrote: > On 7/16/18 1:17 PM, Alex Balashov wrote: > > Hi, > > > > I have a scenario where a call is forked

Re: [Sip-implementors] Offer/answer model in early media with forking

On 7/16/18 1:17 PM, Alex Balashov wrote: Hi, I have a scenario where a call is forked through a proxy to an early media announcement server and then subsequently to a SIP provider for actual termination. Due to the way the RTP relay works on the server side, this results in two different SDP

[Sip-implementors] Offer/answer model in early media with forking

Hi, I have a scenario where a call is forked through a proxy to an early media announcement server and then subsequently to a SIP provider for actual termination. Due to the way the RTP relay works on the server side, this results in two different SDP offers from the two respective outgoing

[Sip-implementors] Offer Answer Model During Early Dialog

Hi,   Please refer the diagram below Callflow diagram  1)  A   -    INVITE [ Support: 100 rel] without SDP   -->  B  2) A   <--   180 Ringing [Require: 100 rel] with SDP offer B 3)  A      PRACK without SDP  

Re: [Sip-implementors] Offer Answer Model During Early Dialog

AFAIK, both of the flows are incorrect. In first case, if SDP offer is in reliable provisional response, PRACK must contain SDP answer. UPDATE can be used any time once SDP offer answer has been done in provisional response and PRACK. Best Regards, Vivek Batra On Fri, Dec 18, 2015 at 6:15 PM,

Re: [Sip-implementors] Offer Answer Model During Early Dialog

Hi Sourav, Adding some more info as below, Take practical scenario When 180 ringing is sent means device started ringing and user can send 200 ok for invite at any time. So there might 200 ok before update is sent. This might lead to ghost call scenario. In case of invite without sdp, 200ok

Re: [Sip-implementors] Offer Answer Model During Early Dialog

I agree with the other responses to this query. See RFC6337 for more detail. Thanks, Paul On 12/18/15 7:45 AM, Sourav Dhar Chaudhuri wrote: Hi, Please refer the diagram below Callflow diagram 1) A -INVITE [ Support: 100 rel] without SDP

Re: [Sip-implementors] Offer Answer Model During Early Dialog

Hi Paul,  Thanks for your response. That means both diagrams are wrong. Answer MUST be present PRACK for the diagram mentioned in my mail as mentioned in RFC 3262.    Please confirm my understanding. Thanks,Sourav On Friday, 18 December 2015 9:17 PM, Paul Kyzivat

Re: [Sip-implementors] Offer Answer Model During Early Dialog

On 12/18/15 12:14 PM, Sourav Dhar Chaudhuri wrote: Hi Paul, Thanks for your response. That means both diagrams are wrong. Answer MUST be present PRACK for the diagram mentioned in my mail as mentioned in RFC 3262. Yes. Please confirm my understanding. Thanks, Sourav On Friday, 18

[Sip-implementors] Offer answer model

Hi Paul/Dale/Ankur, Thanks for your reply. below is the scenario please help resolve it. Below is the updated scenario. sorry for confusion by making step2 as recvonly. now it is fine. The problem here is that after step 9 call becomes audio only. Video disappears.

Re: [Sip-implementors] Offer answer model.... Updated

On 6/23/15 10:23 PM, isshed wrote: Hi Paul, Below is the updated scenario. sorry for confusion by making step2 as recvonly. now it is fine. The problem here is that after step 9 call becomes audio only. Video disappears.

Re: [Sip-implementors] Offer answer model.... Updated

Thanks Paul. For details reply. Please find my response inline. On Wed, Jun 24, 2015 at 8:45 PM, Paul Kyzivat pkyzi...@alum.mit.edu wrote: On 6/23/15 10:23 PM, isshed wrote: Hi Paul, Below is the updated scenario. sorry for confusion by making step2 as recvonly. now it is fine. The problem

[Sip-implementors] Offer answer model

Hi All, Below is the scenario.. UAC1UAC2 1)-INVITE (a=sendrecv)- 2)-200-OK(a=recvonly)-

Re: [Sip-implementors] Offer answer model.... Updated

Hi All, Below is the scenario.. UAC1UAC2 1)-INVITE (a=sendrecv)- 2)-200-OK(a=recvonly)-

Re: [Sip-implementors] Offer answer model

On 6/23/15 9:13 AM, isshed wrote: I seem to have made a career for myself discussing questions like this! Hi All, Below is the scenario.. UAC1UAC2 1)-INVITE (a=sendrecv)-

Re: [Sip-implementors] Offer answer model.... Updated

I saw this after replying to the prior message. But I don't see anything here that alters my reply. Thanks, Paul On 6/23/15 9:16 AM, isshed wrote: Hi All, Below is the scenario.. UAC1UAC2

Re: [Sip-implementors] Offer answer model

isshed isshed@gmail.com writes: UAC1UAC2 1)-INVITE (a=sendrecv)- 2)-200-OK(a=recvonly)-

Re: [Sip-implementors] Offer answer model

As all mentioned its all possible to send any direction till UE follows offer-answer model but its lacking actual use-case and seems ill-logical. Just want to share one point regarding step 4 , where UAC2 sending sendonly and it seems UAC2 suddenly have something to send which he was not having in

Re: [Sip-implementors] Offer answer model

Thanks for response Dale. there is a typo fro 2nd message. read it as a=sendrecv. Meaning call get Successfully connected with audio and video. On Wed, Jun 24, 2015 at 8:44 AM, Dale R. Worley wor...@ariadne.com wrote: isshed isshed@gmail.com writes:

Re: [Sip-implementors] Offer/answer model and multicast

Jānis Rukšāns janis.ruks...@gmail.com writes: I'm wondering what was the reason behind this change from RFC 2543. Session updates where the roles of the offerer and answerer are reversed? My guess is that at the time, people conceptualized the use of multicast within SIP in one way: There is

Re: [Sip-implementors] Offer/answer model and multicast

Hello Dale, Thanks for replying. On Wed, 2014-12-10 at 21:35 -0500, Dale R. Worley wrote: There is a discussion of the use of multicast in RFC 3264 section 5.2 (which is considerably different from the discussion in the first version of SIP in RFC 2543 appendix B): snip Which seems to

Re: [Sip-implementors] Offer/answer model and multicast

Jānis Rukšāns janis.ruks...@gmail.com writes: I believe that I've stumbled upon a contradiction in / between RFC 3264 and RFC 2327/4566 with regard to the interpretation of the sendonly and recvonly attributes for multicast streams. Yes, the interpretation of sendonly and recvonly in regard to

[Sip-implementors] Offer/answer model and multicast

Hello, We are considering adding SIP as one of the means of session negotiation to some of our products that support both unicast and multicast. I believe that I've stumbled upon a contradiction in / between RFC 3264 and RFC 2327/4566 with regard to the interpretation of the sendonly and

Re: [Sip-implementors] offer answer model

Hi Paul, Thanks for the correction. Regards, -Praveen. On Sat, Jan 11, 2014 at 12:27 AM, Paul Kyzivat pkyzi...@alum.mit.eduwrote: On 1/10/14 3:40 AM, Praveena Ss wrote: Hi Isshed, in your example, second offer from A is correct as long as session version id is changed in same

Re: [Sip-implementors] offer answer model

Hi Isshed, in your example, second offer from A is correct as long as session version id is changed in same session. w.r.t m= line, the second answer sent from B is wrong because it does not contain the same number of m= lines as in second offer from A. Hope this helps to you. snippet from RFC

Re: [Sip-implementors] offer answer model

On 1/10/14 3:40 AM, Praveena Ss wrote: Hi Isshed, in your example, second offer from A is correct as long as session version id is changed in same session. I disagree. The operable issue is in section 8 of 3264: If an SDP is offered, which is different from the previous SDP, the new

[Sip-implementors] offer answer model

Hi All, Below is offer answer model between UA A and B. [Offer From A] v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMU/8000 a=rtpmap:8

Re: [Sip-implementors] Offer/Answer model query

Hi Kumar, Yes you are correct. The UAS can not initiate subsequent offer if it has already sent or received answer of offer in initial transaction. Reference Refer RFC 3261: Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent

Re: [Sip-implementors] Offer/Answer model query

Equipment) Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Offer/Answer model query Hi Kumar, Yes you are correct. The UAS can not initiate subsequent offer if it has already sent or received answer of offer in initial transaction. Reference Refer RFC 3261