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 origin
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 no
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, 2018
On 7/16/18 2:00 PM, Alex Balashov wrote:
It should be noted that the UA with which I am testing (Freeswitch) does
not CANCEL or otherwise hang up the first dialog.
In this case, since the proxy did the forking, it SHOULD (MUST?) send a
CANCEL. So it will probably be ok.
Thanks,
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 problem
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 t
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 of
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 De
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
wrote:
I agree with t
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
---
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 co
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, So
Thanks Paul. For details reply. Please find my response inline.
On Wed, Jun 24, 2015 at 8:45 PM, Paul Kyzivat 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 here is tha
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.
UAC1UA
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
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 wrote:
> isshed writes:
>> UAC1UAC2
isshed writes:
> UAC1UAC2
>
> 1)-INVITE (a=sendrecv)->
> 2)<-200-OK(a=recvonly)-
> 3)---ACK---
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
1)-
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)->
2)<-
Hi All,
Below is the scenario..
UAC1UAC2
1)-INVITE (a=sendrecv)->
2)<-200-OK(a=recvonly)-
3)---ACK--
Jānis Rukšāns 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 a single multicast ad
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):
> Which seems to sugge
Jānis Rukšāns 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 what
direction i
Hi Paul,
Thanks for the correction.
Regards,
-Praveen.
On Sat, Jan 11, 2014 at 12:27 AM, Paul Kyzivat wrote:
> 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 dis
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
n
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 3
Hi Isshed,
The new SDP must have a matching media stream for each media stream in
previous SDP. Therefore, second offer from B is invalid and must be
rejected by A. Please refer RFC-3264, section-8.
" If an SDP is offered, which is different from the previous SDP, the
new SDP MUST have a matc
> I hope this holds good, even if there is change
> of offer/answer in between (18X reliable & 200 ok).
> My doubt is that, the UAS can still send the same
> session description in 200 ok (of Invite) as in 18x
> (reliable). This session description could be
> different from what was exchanged p
e) in this case? Or if present, the
> UAC should ignore it?
>
> Thanks,
> kumar
>
>
> From: Vivek Talwar [mailto:vivek.tal...@globallogic.com]
> Sent: Friday, July 27, 2012 4:51 PM
> To: Kumar Ramadoss (WT01 - GMT-Telecom Equipment)
> Cc: sip-implementors@lists.cs.columbi
> Whether below mentioned scenarios correct from
> Offer/Answer model point of view ?
>
> 1. INVITE/18x (Reliable) for Offer/Answer1.
>
> 200 OK (INVITE)/ACK for Offer/Answer2.
No.
> 2. INVITE/18x (Reliable) for Offer/Answer1.
>
> PRACK/200 OK (PRACK) for Offer/Answer2.
Yes.
> 2
ecom 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
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 off
32 matches
Mail list logo
