Re: [Sip-implementors] is Contact Header Mandatory and could be anonymous in the INVITE
> On Sat, Mar 3, 2018 at 7:33 PM, Dale R. Worley wrote: > >> Zuniga, Guillermo writes: >> > I Access enviroment not PEER to PEER connection, CONTACT could be >> > anonymous or always should be any valid uri-user? >> >> The Contact always has to be a valid URI. However, that URI does not >> have to be the AOR (address-of-record) of a customer; it just has to be >> able to reach the UA (when used by the next proxy in the signaling >> path). There are a lot of complexities. Certainly, the Contact has to be a syntactically correct URI. But there are various ways to avoid divulging user-sensitive information. See 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J. Peterson. November 2002. (Format: TXT=54116 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3323) 5379 Guidelines for Using the Privacy Mechanism for SIP. M. Munakata, S. Schubert, T. Ohba. February 2010. (Format: TXT=52595 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5379) 5767 User-Agent-Driven Privacy Mechanism for SIP. M. Munakata, S. Schubert, T. Ohba. April 2010. (Format: TXT=23270 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5767) Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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 not sure offhand whether this is a protocol semantics violation. On
> the one hand, RFC 3261 section 13.2.1 ("Creating the Initial INVITE") says:
As Paul says, the RFCs aren't so very clear about it, but each branch
has a separate to-tag and so is a different dialog, and each dialog has
a seperate state machine. So the section 13.2.1 you quote applies to
each branch independently.
> 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 original message, as
that's how the first dialog ends.
> 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.
A lot of low-budget UAs handle many situations incorrectly. Ultimately,
the answer is to avoid using them, because otherwise you're spending all
your time adjusting your software to try to figure out what the UA is
and avoiding its flaws.
Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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, 2018 6:24:35 PM EDT, Paul Kyzivat wrote:
>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,
> Paul
>
>> 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 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 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 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.
These are both sent back to the UAC?
If so, these should arrive with different to-tags, and so will
>establish
distinct early dialogs. Those can coexist. Then when the 200
>arrives,
(regardless of which dialog it comes on), the UAC should send a
>CANCEL on
the other dialog (to the Contact URI for that dialog. Or it can
>send a BYE.
There is a race condition where you get a 200 on *both* early
>dialogs. In
that case you have two separate calls to deal with. Then you can
>send a BYE
on one of them, or manage them both separately, or treat them as a
conference, or whatever you want.
OTOH, if perchance the two 183 responses have the *same* to-tag,
>then you
have an error situation.
Thanks,
Paul
> I am not sure offhand whether this is a protocol semantics
>violation. On
> the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE")
>says:
>
> If the initial offer is in an INVITE, the answer MUST be in a
> reliable non-failure message from UAS back to UAC which is
> correlated to that INVITE. For this specification, that is
> only the final 2xx response to that INVITE. That same exact
> answer MAY also be placed in any provisional responses sent
> prior to the answer. The UAC MUST treat the first session
> description it receives as the answer, and MUST ignore any
> session descriptions in subsequent responses to the initial
> INVITE.
>
> So, I always understood that the first answer is the final answer,
> absent a session-updating request cycle. On the other hand, RFC
>3960
> ("Early Media and Ringing Tone Generation in the Session
>Initiation
> Protocol (SIP)") Section 4 says:
>
> The application server model consists of having the UAS
>behave as an
> application server to establish early media sessions with the
>UAC.
> The UAC indicates support for the early-session disposition
>type
> (defined in [2]) using the early-session option tag. This
>way, UASs
> know that they can keep offer/answer exchanges for early
>media
> (early-session disposition type) separate from regular media
>(session
> disposition type).
>
> I take this, along with RFC 3959 Section 3, to imply an amendment
>to
> 3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all
>UAs
> will handle this situation.
>
> Any insight would be appreciated!
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>>> --
>>> Alex Balashov | Principal | Evariste Systems LLC
>>>
>>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>> ___
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>
>___
>Sip-implementors mailing list
>Sip-implementors@lists.cs.columbia.edu
>https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
-- Alex
--
Sent via mobile, please forgive typos and brevity.
___
Sip-implementors mailing list
Sip-imp
Re: [Sip-implementors] Offer/answer model in early media with forking
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,
Paul
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 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 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 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.
These are both sent back to the UAC?
If so, these should arrive with different to-tags, and so will establish
distinct early dialogs. Those can coexist. Then when the 200 arrives,
(regardless of which dialog it comes on), the UAC should send a CANCEL on
the other dialog (to the Contact URI for that dialog. Or it can send a BYE.
There is a race condition where you get a 200 on *both* early dialogs. In
that case you have two separate calls to deal with. Then you can send a BYE
on one of them, or manage them both separately, or treat them as a
conference, or whatever you want.
OTOH, if perchance the two 183 responses have the *same* to-tag, then you
have an error situation.
Thanks,
Paul
I am not sure offhand whether this is a protocol semantics violation. On
the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
So, I always understood that the first answer is the final answer,
absent a session-updating request cycle. On the other hand, RFC 3960
("Early Media and Ringing Tone Generation in the Session Initiation
Protocol (SIP)") Section 4 says:
The application server model consists of having the UAS behave as an
application server to establish early media sessions with the UAC.
The UAC indicates support for the early-session disposition type
(defined in [2]) using the early-session option tag. This way, UASs
know that they can keep offer/answer exchanges for early media
(early-session disposition type) separate from regular media (session
disposition type).
I take this, along with RFC 3959 Section 3, to imply an amendment to
3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
will handle this situation.
Any insight would be appreciated!
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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 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 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 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.
> >
> > These are both sent back to the UAC?
> >
> > If so, these should arrive with different to-tags, and so will establish
> > distinct early dialogs. Those can coexist. Then when the 200 arrives,
> > (regardless of which dialog it comes on), the UAC should send a CANCEL on
> > the other dialog (to the Contact URI for that dialog. Or it can send a BYE.
> >
> > There is a race condition where you get a 200 on *both* early dialogs. In
> > that case you have two separate calls to deal with. Then you can send a BYE
> > on one of them, or manage them both separately, or treat them as a
> > conference, or whatever you want.
> >
> > OTOH, if perchance the two 183 responses have the *same* to-tag, then you
> > have an error situation.
> >
> > Thanks,
> > Paul
> >
> > > I am not sure offhand whether this is a protocol semantics violation. On
> > > the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
> > >
> > > If the initial offer is in an INVITE, the answer MUST be in a
> > > reliable non-failure message from UAS back to UAC which is
> > > correlated to that INVITE. For this specification, that is
> > > only the final 2xx response to that INVITE. That same exact
> > > answer MAY also be placed in any provisional responses sent
> > > prior to the answer. The UAC MUST treat the first session
> > > description it receives as the answer, and MUST ignore any
> > > session descriptions in subsequent responses to the initial
> > > INVITE.
> > >
> > > So, I always understood that the first answer is the final answer,
> > > absent a session-updating request cycle. On the other hand, RFC 3960
> > > ("Early Media and Ringing Tone Generation in the Session Initiation
> > > Protocol (SIP)") Section 4 says:
> > >
> > > The application server model consists of having the UAS behave as an
> > > application server to establish early media sessions with the UAC.
> > > The UAC indicates support for the early-session disposition type
> > > (defined in [2]) using the early-session option tag. This way, UASs
> > > know that they can keep offer/answer exchanges for early media
> > > (early-session disposition type) separate from regular media (session
> > > disposition type).
> > >
> > > I take this, along with RFC 3959 Section 3, to imply an amendment to
> > > 3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
> > > will handle this situation.
> > >
> > > Any insight would be appreciated!
> > >
> >
> > ___
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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 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 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.
>
> These are both sent back to the UAC?
>
> If so, these should arrive with different to-tags, and so will establish
> distinct early dialogs. Those can coexist. Then when the 200 arrives,
> (regardless of which dialog it comes on), the UAC should send a CANCEL on
> the other dialog (to the Contact URI for that dialog. Or it can send a BYE.
>
> There is a race condition where you get a 200 on *both* early dialogs. In
> that case you have two separate calls to deal with. Then you can send a BYE
> on one of them, or manage them both separately, or treat them as a
> conference, or whatever you want.
>
> OTOH, if perchance the two 183 responses have the *same* to-tag, then you
> have an error situation.
>
> Thanks,
> Paul
>
> > I am not sure offhand whether this is a protocol semantics violation. On
> > the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
> >
> > If the initial offer is in an INVITE, the answer MUST be in a
> > reliable non-failure message from UAS back to UAC which is
> > correlated to that INVITE. For this specification, that is
> > only the final 2xx response to that INVITE. That same exact
> > answer MAY also be placed in any provisional responses sent
> > prior to the answer. The UAC MUST treat the first session
> > description it receives as the answer, and MUST ignore any
> > session descriptions in subsequent responses to the initial
> > INVITE.
> >
> > So, I always understood that the first answer is the final answer,
> > absent a session-updating request cycle. On the other hand, RFC 3960
> > ("Early Media and Ringing Tone Generation in the Session Initiation
> > Protocol (SIP)") Section 4 says:
> >
> > The application server model consists of having the UAS behave as an
> > application server to establish early media sessions with the UAC.
> > The UAC indicates support for the early-session disposition type
> > (defined in [2]) using the early-session option tag. This way, UASs
> > know that they can keep offer/answer exchanges for early media
> > (early-session disposition type) separate from regular media (session
> > disposition type).
> >
> > I take this, along with RFC 3959 Section 3, to imply an amendment to
> > 3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
> > will handle this situation.
> >
> > Any insight would be appreciated!
> >
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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 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.
These are both sent back to the UAC?
If so, these should arrive with different to-tags, and so will establish
distinct early dialogs. Those can coexist. Then when the 200 arrives,
(regardless of which dialog it comes on), the UAC should send a CANCEL
on the other dialog (to the Contact URI for that dialog. Or it can send
a BYE.
There is a race condition where you get a 200 on *both* early dialogs.
In that case you have two separate calls to deal with. Then you can send
a BYE on one of them, or manage them both separately, or treat them as a
conference, or whatever you want.
OTOH, if perchance the two 183 responses have the *same* to-tag, then
you have an error situation.
Thanks,
Paul
I am not sure offhand whether this is a protocol semantics violation. On
the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
So, I always understood that the first answer is the final answer,
absent a session-updating request cycle. On the other hand, RFC 3960
("Early Media and Ringing Tone Generation in the Session Initiation
Protocol (SIP)") Section 4 says:
The application server model consists of having the UAS behave as an
application server to establish early media sessions with the UAC.
The UAC indicates support for the early-session disposition type
(defined in [2]) using the early-session option tag. This way, UASs
know that they can keep offer/answer exchanges for early media
(early-session disposition type) separate from regular media (session
disposition type).
I take this, along with RFC 3959 Section 3, to imply an amendment to
3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
will handle this situation.
Any insight would be appreciated!
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[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 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 not sure offhand whether this is a protocol semantics violation. On
the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
So, I always understood that the first answer is the final answer,
absent a session-updating request cycle. On the other hand, RFC 3960
("Early Media and Ringing Tone Generation in the Session Initiation
Protocol (SIP)") Section 4 says:
The application server model consists of having the UAS behave as an
application server to establish early media sessions with the UAC.
The UAC indicates support for the early-session disposition type
(defined in [2]) using the early-session option tag. This way, UASs
know that they can keep offer/answer exchanges for early media
(early-session disposition type) separate from regular media (session
disposition type).
I take this, along with RFC 3959 Section 3, to imply an amendment to
3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
will handle this situation.
Any insight would be appreciated!
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
