Re: [Sip-implementors] What does identical mean?

[Paul Kyzivat]

I should have noticed Dale's reply before writing my own that says the 
same thing.


Thanks,
Paul

On 5/26/15 7:07 AM, Dale R. Worley wrote:

Ren Xin  writes:

Our product actually compare the newly received SDP with previous one and
if they are not byte-to-byte identical and the SDP version does not
increase by 1, we invalidate the stream.

Customer is complaining about this. They think these two streams are
identical.

Now we can not reach an agreement on if this is a bug.


I would argue that "identical" requires that they be byte-by-byte the
same.  On the other hand, why is your product attempting to enforce this
rule?  I would expect that the benefit of the rule "If the version in
the origin line does not increment, the SDP MUST be identical to the SDP
with that version number." is that if the version number is the same as
before, the device can skip parsing the SDP and leave its media
configuration the same as before.  If the device is taking the trouble
to do a complete inspection of the SDP anyway and actually comparing it
to the previous SDP, why is it being particular about the version
number?

"Be conservative in what you produce; be liberal in what you accept."

Dale



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] What does identical mean?

[Paul Kyzivat]

On 5/26/15 4:50 AM, Ren Xin wrote:

Our product actually compare the newly received SDP with previous one
and if they are not byte-to-byte identical and the SDP version does not
increase by 1, we invalidate the stream.

Customer is complaining about this. They think these two streams are
identical.

Now we can not reach an agreement on if this is a bug.


I think this depends on your objectives.

If your goal is to be "SDP Police" and verify that others adhere to the 
letter of the specs, then you are probably doing the right thing.


If your goal is to maximize interoperability, then not so much. In that 
case you are better to follow the Postel maxim: “Be liberal in what you 
accept, and conservative in what you send.”


You just need to be sensible in how you are liberal. (IMO it isn't good 
to be liberal by choosing one of two equally plausible interpretations 
of an ambiguous point.)


IMO it would probably be a bad thing if you simply trusted that the 
version being equal means the SDP is unchanged. In that case, if 
somebody screwed up and made big changes to the SDP and failed to change 
the version you could get into big interop problems.


But if, when you find the SDPs are not byte-by-byte identical, you act 
as if the version was updated even if it was not, then ISTM the only 
"harm" that can arise is that you might succeed in interoperating.


But it is your choice.

Thanks,
Paul


On Mon, May 25, 2015 at 6:31 PM, Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote:

On 5/25/15 6:45 AM, Ren Xin wrote:

Hey,



According to RFC 3264 par.7

"If the version in the origin

line does not increment, the SDP MUST be identical to the
SDP with

that version number.  The answerer MUST be prepared to
receive an

offer that contains SDP with a version that has not changed;
this is

effectively a no-op.  However, the answerer MUST generate a
valid

answer (which MAY be the same as the previous SDP from the
answerer,

or MAY be different), according to the procedures defined in
Section 6."



Do you think following two SDP offers are identical?


This was always less than clear to me too.

The obvious definition would be byte-by-byte identical. But is there
any point in deciding they are not identical?

ISTM an operational definition makes more sense:

A recipient that sees that the version is unchanged may assume that
the this is functionally the same as the last one received and not
further check or process it. By that definition, these are identical
enough.

Personally, I have always thought that it is dangerous to trust
this. I would prefer to actually do my own comparison before
deciding to optimize this way. Then if they aren't byte-by-byte
identical then just go ahead and process the new one as if the
version was different.

 Thanks,
 Paul

# SDP 1
v=0
o=MxSIP 1751268753124820177 614423801163363146 IN IP4 10.249.130.34
s=-
c=IN IP4 10.249.130.34
t=0 0
*a=sendrecv*
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15


# SDP 2
v=0
o=MxSIP 1751268753124820177 614423801163363146 IN IP4 10.249.130.34
s=-
c=IN IP4 10.249.130.34
t=0 0
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15




I checked marriam-webster, and it seems that definition
1(selfsame) makes
them not identical, while definition 2(essentially same) makes them
identical.

www.merriam-webster.com/dictionary/identical
<http://www.merriam-webster.com/dictionary/identical>


What do you think?

Best Regards,
Xin
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto: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
<mailto: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] What does identical mean?

[Paul Kyzivat]

On 5/25/15 6:45 AM, Ren Xin wrote:

Hey,



According to RFC 3264 par.7

"If the version in the origin

   line does not increment, the SDP MUST be identical to the SDP with

   that version number.  The answerer MUST be prepared to receive an

   offer that contains SDP with a version that has not changed; this is

   effectively a no-op.  However, the answerer MUST generate a valid

   answer (which MAY be the same as the previous SDP from the answerer,

   or MAY be different), according to the procedures defined in Section 6."



Do you think following two SDP offers are identical?


This was always less than clear to me too.

The obvious definition would be byte-by-byte identical. But is there any 
point in deciding they are not identical?


ISTM an operational definition makes more sense:

A recipient that sees that the version is unchanged may assume that the 
this is functionally the same as the last one received and not further 
check or process it. By that definition, these are identical enough.


Personally, I have always thought that it is dangerous to trust this. I 
would prefer to actually do my own comparison before deciding to 
optimize this way. Then if they aren't byte-by-byte identical then just 
go ahead and process the new one as if the version was different.


Thanks,
Paul


# SDP 1
v=0
o=MxSIP 1751268753124820177 614423801163363146 IN IP4 10.249.130.34
s=-
c=IN IP4 10.249.130.34
t=0 0
*a=sendrecv*
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15


# SDP 2
v=0
o=MxSIP 1751268753124820177 614423801163363146 IN IP4 10.249.130.34
s=-
c=IN IP4 10.249.130.34
t=0 0
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15




I checked marriam-webster, and it seems that definition 1(selfsame) makes
them not identical, while definition 2(essentially same) makes them
identical.

www.merriam-webster.com/dictionary/identical


What do you think?

Best Regards,
Xin
___
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] Q regarding call transfer and P-Asserted-Identity

[Paul Kyzivat]

ISTM that this is a value judgement on the part of the PBX - exactly how 
it thinks its transfer feature should work. In particular, does it 
*want* to disclose to the caller that a transfer has occurred.


Thanks,
Paul

On 5/12/15 11:55 AM, ankur bansal wrote:

Hi Roger

Cisco PBX behavior seems correct here .Also after transfer is complete in
step 3 ,
Phone-A is out of picture after having BYE exchange with Phone-B and PBX.
So during step 4, PBX should use PAI of Phone-B.

Regards
Ankur Bansal

On Tue, May 12, 2015 at 4:55 PM, Roger Wiklund 
wrote:


Hi folks!

Scenario:

ITSP--PBX--PHONE-A--PHONE-B

1. Call from PSTN via ITSP to PHONE-A (via B2BUA PBX)
2. PHONE-A answers the call
3. PHONE-A makes a supervised transfer to PHONE-B (REFER within the PBX)
4. PBX sends UPDATE/Re-INVITE to ITSP with updated SDP containing
connection details to PHONE-B.
5. PHONE-B is now talking to the PSTN

In the above scenario using a Cisco Callmanager PBX, during step 4.
P-Asserted-Identity containing PHONE-B is included in the UPDATE/Re-INVITE
to the ITSP.

In the same scenario using a Mitel MX-One PBX, during step 4,
P-Asserted-Identity is included containing PHONE-A in the UPDATE/Re-Invite
to the ITSP.

I'm struggling with this as we are using a recording solution and with
Mitel MX-One the SRS cannot tell that the call has been transferred.

Section 3.2 describes they way Cisco does it (my interpretation at least)
https://tools.ietf.org/html/rfc5876#section-3.2

What's the correct way to implement this? The Cisco way or the Mitel way?
What's your take on this?

Thanks
/Roger
___
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



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SIP Call on hold - Reinvite Session Attribute Vs Media Attribute

[Paul Kyzivat]

On 5/12/15 9:35 AM, Sylvester, Prasanth (Nokia - IN/Mumbai) wrote:

Hi Team,

I've a small doubt. I have a working call where A party is talking to B party. B party putts the 
call on hold, however I see "Session Attribute" with a value "SendOnly". Mostly 
I've seen it coming in Media Attribute.

"Session Attribute (a): sendonly" Instead of "Media Attribute (a): SendOnly".

What's the difference?


When used at session level this attribute serves as a default for each 
media section. So this means sendonly for *all* the media in the call, 
except for media sections that explicitly override it.


In the case where there is only one media section (audio) it means 
exactly the same thing if it only appears at session level as it does if 
it only appears at media level.


You should code your SDP attribute processing more or less as follows:

1) initialize the default media direction to sendrecv
2) process session level attributes
2.1) if you encounter any of sendrecv/sendonly/recvonly/inactive,
 replace the default media direction with that.
3) when you encounter m=
3.1) set the direction for that media section to the default
 media direction determined by (1)-(2).
3.2) process the attributes for that media section
3.2.1) if you encounter any of sendrecv/sendonly/recvonly/inactive,
   replace the direction for that media section with it
3.3) the final value for this media section is the direction
 that this SDP specifies for this media section.
4) repeat (3) for the other media sections

Thanks,
Paul


I've read some phone (PolyCom) while its set to a different settings, do this.
For e.g
voIpProt.SIP.useRFC2543hold 0 or 1  0

When the phone is set to 0,  use SDP media direction parameters (such as 
a=sendonly) per RFC 3264
Otherwise use the obsolete c=0.0.0.0 RFC2543 technique

Could someone throw some light? Just trying to figure out the difference?

Cheers,

Sylvester


___
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] URI value mandatory for Alert-Info?

[Paul Kyzivat]

On 5/12/15 10:27 AM, CALME, Jim (Jim)** CTR ** wrote:

Hi Paul,

Would it be feasible to use a "data" URL scheme as defined by RFC 2397?

data:[][;base64],

With this syntax, the “mediatype” and “base64” are optional and may be
omitted leaving the “,” available for carrying information as an
alternative to the Alert-Info generic-param.


The above is *possible* syntactically. I don't think anyone can raise an 
argument that using it in a proprietary implementation would violate 
anything. But you would never be able to get a draft that proposed such 
a usage approved.



Though I would agree that depending on the application, there may be a
better alternative.


Again I have to ask what the use case is. Having an alert-info with a 
parameter and no URI makes no sense to me. The most likely reason I can 
think for wanting to do that is covered by RFC7462.


Thanks,
Paul


Thanks,

Jim

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Paul Kyzivat
Sent: Tuesday, May 12, 2015 9:12 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] URI value mandatory for Alert-Info?

On 5/11/15 9:12 PM, Alex Balashov wrote:

 > Hello,

 >

 > The ABNF grammar for Alert-Info is:

 >

 > Alert-Info   =  "Alert-Info" HCOLON alert-param *(COMMA alert-param)

 > alert-param  =  LAQUOT absoluteURI RAQUOT *( SEMI generic-param )

 >

 > I have an application that seems to utilise just a generic-param

 > without a URI. However, I don't see any */? quantifiers for

 > absoluteURI which suggest that it's optional:

 >

 > absoluteURI=  scheme ":" ( hier-part / opaque-part )

 >

 > Maybe it's a failure on my part to properly understand ABNF, however.

 >

 > My fundamental question is: is there any grammatically acceptable way

 > to have an Alert-Info header value consisting of no URI and just a

 > generic-param, e.g.

 >

 > Alert-Info: ;internal=xyz

 > Alert-Info: <>;internal=xyz

No there isn't. There was no intent to allow that.

Can you say more about what you are trying to accomplish? It sounds like
an abuse of Alert-Info. If you explain, maybe we can find a way to
achieve your intent.

   Thanks,

   Paul

___

Sip-implementors mailing list

Sip-implementors@lists.cs.columbia.edu
<mailto: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] URI value mandatory for Alert-Info?

[Paul Kyzivat]

On 5/11/15 9:12 PM, Alex Balashov wrote:

Hello,

The ABNF grammar for Alert-Info is:

Alert-Info   =  "Alert-Info" HCOLON alert-param *(COMMA alert-param)
alert-param  =  LAQUOT absoluteURI RAQUOT *( SEMI generic-param )

I have an application that seems to utilise just a generic-param without
a URI. However, I don't see any */? quantifiers for absoluteURI which
suggest that it's optional:

absoluteURI=  scheme ":" ( hier-part / opaque-part )

Maybe it's a failure on my part to properly understand ABNF, however.

My fundamental question is: is there any grammatically acceptable way to
have an Alert-Info header value consisting of no URI and just a
generic-param, e.g.

Alert-Info: ;internal=xyz
Alert-Info: <>;internal=xyz


No there isn't. There was no intent to allow that.

Can you say more about what you are trying to accomplish? It sounds like 
an abuse of Alert-Info. If you explain, maybe we can find a way to 
achieve your intent.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] To tag changing during Call Forwarding

[Paul Kyzivat]

On 5/5/15 10:46 AM, Sourav Dhar Chaudhuri wrote:

Hi Paul & Brett,
   Thanks for your detailed clarification. Just final doubt if in the
INVITE request will have "Request-Disposition: no-fork" then Call
forwarding will not happen for that request ?


Yes, *IF* the proxy honored that. But the callerpref stuff is all 
optional, and frankly I'm not aware of *any* implementation that honors 
no-fork. :-(


Thanks,
Paul


Thanks,
Sourav



On Tuesday, 5 May 2015 6:53 PM, Paul Kyzivat  wrote:


On 5/5/15 4:21 AM, Sourav Dhar Chaudhuri wrote:
 > Hi Paul,
 >Thanks for your response. So it means the Call Forwarding always
 > need minimum requirement that Caller [UAC] must have support for
 > handling forking response in case SBC does not have the "fix" you
mentioned.
 >
 >  Also my second doubt why this thing not been properly highlighted
 > in RFC 5359.  Is support to handle forking response is mandatory
 > requirement for a SIP Caller [UAC]?

I wasn't an author of that, so can't say for certain. But it has a
normative reference on RFC3261. And support for multiple early dialogs,
at least to the extent I described, is not optional there. It would get
tiresome for every sip document to emphasize every mandatory feature of
3261 that must be supported.

 Thanks,
 Paul

 > Thanks,
 > Sourav
 >
 >
 >
 > On Monday, 4 May 2015 9:38 PM, Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote:
 >
 >
 > On 5/4/15 10:49 AM, Sourav Dhar Chaudhuri wrote:
 >  > Hi ,  I have a question on To tag change during Call Forwarding
 > [Unconditional / Busy/ No Answer]. As per RFC 5359, it can be noticed
 > that To tag value is getting changed from 181 Call is being forwarded to
 > 180 Ringing response during Call Forwarding.
 >  >Now my query is if a caller does not support forking then any call
 > originated from that caller will never be forwarded? Since To tag value
 > is getting changed during Call Forwarding.
 >  >Also how the caller is maintaining the state during call
 > Forwarding? Since initial INVITE is getting two provisional response
 > having two different To tag. For the initial provisional response there
 > is no final response. Only the final response is coming from the
 > transferred callee.  Then what will be the status of the call leg
 > generated for first provisional response?
 >
 > This is basic SIP. A UAC that doesn't support this is *broken*.
 >
 > When you see the first to-tag that establishes one early dialog. When
 > you see the 2nd to-tag that establishes a 2nd early dialog. You need to
 > maintain state for those independently.
 >
 > When you get a 200 response on the 2nd early dialog you don't know with
 > certainty whether the first dialog is gone or not. It is *possible* that
 > you could still get a 200 response on that dialog until it times out,
 > even though it is more likely that it has been canceled downstream.
 >
 > I think there are SBCs that "fix" this by hiding the existence of two
 > dialogs from the caller. But the caller can't really depend on that
 > unless it is deployed in an environment where it knows there is always
 > such an SBC in the path.
 >
 >
 >  Thanks,
 >
 >  Paul
 > ___
 > Sip-implementors mailing list
 > Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
 > <mailto:Sip-implementors@lists.cs.columbia.edu
<mailto: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

[Sip-implementors] Anybody know of usage of SDP a=quality?

[Paul Kyzivat]

There is a revision underway on SDP. The a=quality attribute has always 
been underspecified. We would like to tighten up the specification, but 
do so in a backward compatible way with existing usage if possible. So 
far we have not identified any usage of it. If not, we will probably 
leave the specification alone and deprecate it.


So, is anyone here aware of any use of a=quality in the wild?

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] To tag changing during Call Forwarding

[Paul Kyzivat]

On 5/5/15 4:21 AM, Sourav Dhar Chaudhuri wrote:

Hi Paul,
Thanks for your response. So it means the Call Forwarding always
need minimum requirement that Caller [UAC] must have support for
handling forking response in case SBC does not have the "fix" you mentioned.

 Also my second doubt why this thing not been properly highlighted
in RFC 5359.  Is support to handle forking response is mandatory
requirement for a SIP Caller [UAC]?


I wasn't an author of that, so can't say for certain. But it has a 
normative reference on RFC3261. And support for multiple early dialogs, 
at least to the extent I described, is not optional there. It would get 
tiresome for every sip document to emphasize every mandatory feature of 
3261 that must be supported.


Thanks,
Paul


Thanks,
Sourav



On Monday, 4 May 2015 9:38 PM, Paul Kyzivat  wrote:


On 5/4/15 10:49 AM, Sourav Dhar Chaudhuri wrote:
 > Hi ,  I have a question on To tag change during Call Forwarding
[Unconditional / Busy/ No Answer]. As per RFC 5359, it can be noticed
that To tag value is getting changed from 181 Call is being forwarded to
180 Ringing response during Call Forwarding.
 >Now my query is if a caller does not support forking then any call
originated from that caller will never be forwarded? Since To tag value
is getting changed during Call Forwarding.
 >Also how the caller is maintaining the state during call
Forwarding? Since initial INVITE is getting two provisional response
having two different To tag. For the initial provisional response there
is no final response. Only the final response is coming from the
transferred callee.  Then what will be the status of the call leg
generated for first provisional response?

This is basic SIP. A UAC that doesn't support this is *broken*.

When you see the first to-tag that establishes one early dialog. When
you see the 2nd to-tag that establishes a 2nd early dialog. You need to
maintain state for those independently.

When you get a 200 response on the 2nd early dialog you don't know with
certainty whether the first dialog is gone or not. It is *possible* that
you could still get a 200 response on that dialog until it times out,
even though it is more likely that it has been canceled downstream.

I think there are SBCs that "fix" this by hiding the existence of two
dialogs from the caller. But the caller can't really depend on that
unless it is deployed in an environment where it knows there is always
such an SBC in the path.


 Thanks,

 Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto: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] To tag changing during Call Forwarding

[Paul Kyzivat]

On 5/4/15 10:49 AM, Sourav Dhar Chaudhuri wrote:

Hi ,   I have a question on To tag change during Call Forwarding [Unconditional 
/ Busy/ No Answer]. As per RFC 5359, it can be noticed that To tag value is 
getting changed from 181 Call is being forwarded to 180 Ringing response during 
Call Forwarding.
Now my query is if a caller does not support forking then any call 
originated from that caller will never be forwarded? Since To tag value is 
getting changed during Call Forwarding.
Also how the caller is maintaining the state during call Forwarding? Since 
initial INVITE is getting two provisional response having two different To tag. 
For the initial provisional response there is no final response. Only the final 
response is coming from the  transferred callee.  Then what will be the status 
of the call leg generated for first provisional response?


This is basic SIP. A UAC that doesn't support this is *broken*.

When you see the first to-tag that establishes one early dialog. When 
you see the 2nd to-tag that establishes a 2nd early dialog. You need to 
maintain state for those independently.


When you get a 200 response on the 2nd early dialog you don't know with 
certainty whether the first dialog is gone or not. It is *possible* that 
you could still get a 200 response on that dialog until it times out, 
even though it is more likely that it has been canceled downstream.


I think there are SBCs that "fix" this by hiding the existence of two 
dialogs from the caller. But the caller can't really depend on that 
unless it is deployed in an environment where it knows there is always 
such an SBC in the path.


Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Need Urgent Help for Codec issue

[Paul Kyzivat]

On 4/21/15 4:37 AM, ashish rawat wrote:

Hi Nitin,

Yes that is correct! ( Based on the media
direction.send-recv,recvonly,sendonly)

I once again pasting the same RFC, I think this has the answer to your
question.

https://www.ietf.org/rfc/rfc3264.txt

Offerer Processing of the Answer

When the offerer receives the answer, it MAY send media on the
accepted stream(s) (assuming it is listed as sendrecv or recvonly in
the answer). *It MUST send using a media format listed in the answer,
and it SHOULD use the first media format listed in the answer when it
does send.*

*The reason this is a SHOULD, and not a MUST (its also a SHOULD,
   and not a MUST, for the answerer), is because there will
   oftentimes be a need to change codecs on the fly*.  For example,
   during silence periods, an agent might like to switch to a comfort
   noise codec.  Or, if the user presses a number on the keypad, the
   agent might like to send that using RFC 2833 [9].  Congestion
   control might necessitate changing to a lower rate codec based on
   feedback.


The above are all "traditional" reasons. They imply that the SHOULD is 
followed most of the time.


Until recently it was usual (with SIP) that there is only one media 
stream in each direction within an RTP session, and the above made sense 
in that context.


More recently we are seeing use cases where an RTP session carries 
multiple media streams. Within the RTP session these are distinguishable 
by SSRC or other means. And then each of those will likely behave as 
above, with rare codec changes for 2833, etc. But each may use a 
different codec, or not.


There are a lot of *drafts* related to this. You might want to start 
with 
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-19.


Note that *that* uses a separate m-line for each media stream, but ties 
several m-lines together on a single RTP session. So you are still 
negotiating codecs separately per-m-line, so the change isn't so great. 
But your RTP implementation sees them all mixed together and must 
concurrently support multiple codecs.


Of course, bundle only gets used if both the offerer and the answerer 
support it, so you won't get into it accidentally.


But this indicates that styles of usage are evolving. So you may see 
things now that were always legal but weren't normally seen in the past.


The case where codec switching has been common practice forever is with 
a "regular" audio codec plus the 2833 telephone-events codec. But there 
isn't anything *fundamentally* different about that and switching 
between H.264 and VP8.


Thanks,
Paul


There has been no change in the initially exchanged offer/answer. Vendor
is using once of the codes already listed in the answer hence a new
offer/answer or update isn't required.

Thanks,
Ashish



On Tuesday, 21 April 2015 6:05 AM, NK  wrote:


Hi Paul,

Your explanation making sense to me. As you said.

- If X offers two codecs, and Y answers with both of those,
then there is no choice of codec. Either side can send
either codec at any time.

# Is that mean,  if "Y" replied with 2 codec and so any codec can be use by
X (it will not accept as which codec is first) is that correct?
# So is that valid even without sending another offer, Y RTP can use
different codec towards to X for 183 & 180 (whereas we know there is no
change in "m" line of 183 and 180).. Is that correct?

Can you please advise if there is any rfc or document i can check for the
same?

Regards,
Nitin Kapoor



On Mon, Apr 20, 2015 at 4:42 PM, Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote:

 > Anish,
 >
 > It is a little hard to follow you, but I think you still aren't "getting"
 > how it works.
 >
 > - If X offers two codecs, and Y answers with both of those,
 >  then there is no choice of codec. Either side can send
 >  either codec at any time.
 >
 > - If X offers two codecs and Y answers with one of those two,
 >  then X can only send the chosen one to Y, but Y can still
 >  send either codec to X at any time. (Even though this is
 >  probably unlikely to happen.)
 >
 > If you, as X, offer two codecs, and you only want one of them used at a
 > time, then after receiving the first answer from Y, you should send
another
 > offer with only one codec (one that you now know Y supports).
 >
 > It doesn't matter what messages the offers and answers are carried it.
 > Except of course that can be times when you aren't yet allowed to send
 > another offer. During those periods you just have to cope with things as
 > they are.
 >
 >Thanks,
 >Paul
 >
 >
 > On 4/20/15 4:58 PM, NK wrote:
 >
 >> Hi Ashish,
 >>
 >> Thanks for the information. But Michael replied it is clear to me
now, but
 >> 

Re: [Sip-implementors] Need Urgent Help for Codec issue

[Paul Kyzivat]

Anish,

It is a little hard to follow you, but I think you still aren't 
"getting" how it works.


- If X offers two codecs, and Y answers with both of those,
  then there is no choice of codec. Either side can send
  either codec at any time.

- If X offers two codecs and Y answers with one of those two,
  then X can only send the chosen one to Y, but Y can still
  send either codec to X at any time. (Even though this is
  probably unlikely to happen.)

If you, as X, offer two codecs, and you only want one of them used at a 
time, then after receiving the first answer from Y, you should send 
another offer with only one codec (one that you now know Y supports).


It doesn't matter what messages the offers and answers are carried it. 
Except of course that can be times when you aren't yet allowed to send 
another offer. During those periods you just have to cope with things as 
they are.


Thanks,
Paul

On 4/20/15 4:58 PM, NK wrote:

Hi Ashish,

Thanks for the information. But Michael replied it is clear to me now, but
its created 1 confusion as below. Can anyone please help me to get the
answer on this.

Ideally when we have multiple codec from UAS in 183 or 180 so ideally UAC
accept the first codec whatever is there in "m" line and as far as i know
if we have change any codec before 200 OK we should use UPDATE method.
1) But in this case as you can see there was no media changed in "m" line
in 180 after 183 which means no UPDATE required then how without UPDATE
method RTP stream have different codec.
2) Secondly since we have first codec G729 in m=audio 21280 RTP/AVP 18 8
101 of 180 then how RTP stream selected the second preference.
I assume that when we have multiple codec in Answer then UAC select First
In First out method(i mean it will select the first codec)

Regards,
Nitin
On Sat, Apr 18, 2015 at 1:03 AM, ashish rawat 
wrote:


Hi Nitin,

I think it is valid to change the codec on fly. We often see it during
DTMF RFC2833.here isn't any change in existing offer. It's using one of
listed codes in the offer/answer ealier.

https://www.ietf.org/rfc/rfc3264.txt

  The reason this is a SHOULD, and not a MUST (its also a SHOULD,
   and not a MUST, for the answerer), is because there will
   oftentimes be a need to change codecs on the fly.  For example,
   during silence periods, an agent might like to switch to a comfort
   noise codec.  Or, if the user presses a number on the keypad, the
   agent might like to send that using RFC 2833 [9].  Congestion
   control might necessitate changing to a lower rate codec based on
   feedback.

Thanks,
Ashish



   On Saturday, 18 April 2015 5:36 AM, NK  wrote:


Hi Michael,

Thanks for a lot for you reply. Its making sense to me, however its created
1 confusion to me.

As you can ideally when we have multiple codec from UAS in 183 or 180 so
ideally UAC accept the first codec whatever is there in "m" line and as far
as i know if we have change any codec before 200 OK we should use UPDATE
method.

1) But in this case as you can see there was no media changed in "m" line
in 180  after 183 which means no UPDATE required then how without UPDATE
method RTP stream have different codec.

2) Secondly since we have first codec G729 in m=audio 21280 RTP/AVP 18 8
101 of 180 then how RTP stream selected the second preference.

I assume that when we have multiple codec in Answer then UAC select First
In First out method(i mean it will select the first codec)

Regards,
Nitin Kapoor



On Fri, Apr 17, 2015 at 4:02 PM, Michael Bain 
wrote:


Yes this is valid. When you make an SDP offer, you are saying you are
willing to receive any of those codecs at anytime during the session. See
the third paragraph of this section:
http://tools.ietf.org/html/rfc3264#section-5.1

"If multiple formats are listed, it means that the offerer is capable of
making use of any of those formats during the session.  In other words,

the

answerer MAY change formats in the middle of the session, making use of

any

of the formats listed, without sending a new offer."

Mike

On 17 April 2015 at 12:47, NK  wrote:


Dear All,

I am facing the problem where my vendor changed the codec in RTP
packet only. Below is the explanation to this issue.

1) We sent the Invite to vendor and Vendor replied 183 w/SDP along with
below m line. Also since its early media RTP started and agreed to use

G729

Codec as below and UAC is also agreed on same.

m=audio 21280 RTP/AVP 18 8 101

RTP

Media Destination Port= 41354
Direction= InBound
*Payload  = G.729*

  2) Here after we received 180 w/SDP from vendor and SDP remain the

same,

but the RTP packet which redirect to UAC from UAS changed the codec as
below.

m=audio 21280 RTP/AVP 18 8 101

RTP

Media Destination Port= 41354
Direction= InBound
*Payload  = PCMA*

Can you please help me o

Re: [Sip-implementors] Session establishment without media resources allocation

[Paul Kyzivat]

On 2/28/15 8:05 PM, brez wrote:

Hi Paul,

Please see inline..

On 2/28/2015 10:58 PM, Paul Kyzivat wrote:

On 2/28/15 3:36 PM, brez wrote:

Hello,

Is it possible to establish a session (INVITE) with SDP constructed in
such a way so that neither party initiates a media session, nor
allocates resources (ports) for a non-existent media session?


In principle you can send an initial offer with SDP that has no m-lines.

AFAIK that is valid.


Thanks for giving me direction. This is indeed a valid case which is
described in RFC3264, Section 5, Paragraph 4:

  The offer will contain zero or more media streams (each media stream
  is described by an "m=" line and its associated attributes). Zero
  media streams implies that the offerer wishes to communicate, but
  that the streams for the session will be added at a later time
  through a modified offer.


But I have recently had discussions with someone about this, and about
a UAS that wants to return 488 for this case. I *think* that in
*practice* you will find that many UASs will reject such an offer one
way or another.



Would that depend on the policy of service provider? i.e. you don't want
UAC who doesn't know how it wants to communicate, and by returning 488
you get rid of any such clients requesting your service.


Yes, policy is significant here.

The fundamental issue is that a session without media isn't useful in 
the long term. To make it useful, somebody has to do something more - 
typically another offer. But once the first offer is done it isn't clear 
where the responsibility resides? *Who* should do something? And what?


This isn't written down anywhere. Logically, I think it makes sense that 
the UA that caused this media-less situation should be responsible for 
fixing it. So if the initial offer had no m-lines, then that end should 
take responsibility for making another offer to fix it. (Of course, if 
it can, then why didn't it do so in the first offer?)


There is also another case, where the initial offer contains m-lines but 
the answer rejects them all but still accepts the INVITE. *That* case 
makes more sense. It can happen because the offer had no media 
acceptable to the answerer, but there are *some* media that the answerer 
would like to use. But there is danger in accepting the INVITE in this 
case: if the call has been forked, there might be another fork that will 
accept the media in the initial invite. If another UA accepts without 
media, it may preempt that. :-(


There is a special case in the wild: the offer has no media, but is 
accepted. Then messages are exchanged within the dialog using MESSAGE. 
(This is arguably an abuse of MESSAGE.) I think the intent to use the 
dialog this was is signaled somehow, so the answerer knows what to expect.


Bottom line - while this is a *possible* mechanism it seems only suited 
to some special cases.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Session establishment without media resources allocation

[Paul Kyzivat]

On 2/28/15 3:36 PM, brez wrote:

Hello,

Is it possible to establish a session (INVITE) with SDP constructed in
such a way so that neither party initiates a media session, nor
allocates resources (ports) for a non-existent media session?


In principle you can send an initial offer with SDP that has no m-lines.

AFAIK that is valid. But I have recently had discussions with someone 
about this, and about a UAS that wants to return 488 for this case. I 
*think* that in *practice* you will find that many UASs will reject such 
an offer one way or another.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Relative Preference [q] value in SIP

[Paul Kyzivat]

On 2/27/15 8:28 AM, VISHAL GOYAL wrote:

Hi Experts,
As we know, The range of "q" parameter in SIP is between 0 to 1.
Is there any exact limit on the decimal places ?


From 3261:

qvalue =  ( "0" [ "." 0*3DIGIT ] )
  / ( "1" [ "." 0*3("0") ] )



for example : Is q=0.87654 valid ?


No.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] query on presence

[Paul Kyzivat]

On 2/20/15 10:51 AM, a...@ag-projects.com wrote:


On 20 Feb 2015, at 09:50, Sreejith Sadaasivan  
wrote:


Hi All,
I have a doubt on presence subscription of a buddy.

1) whether it is always mandatory to subscribe to a buddy with "SUBSCRIBE" 
message to retrieve the presence of a buddy?


Yes


2) is there anyway we can directly retrieve the presence of a buddy without 
subscribing ( without sending SUBSCRIBE message )


Not by using SIP protocol. NOTIFY messages containing presence payload are sent 
as a result of a previous SUBSCRIBE.


I am afraid that if I try to get a presence of a buddy by SUBSCRIBE message 
then later I need to send an UNSUBSCRIBE to the buddy. if there is anyway to 
directly retrieve the presence of a buddy then we can avoid the UNSUBSCRIBE 
part.


There is no standard way of doing such thing. What you ask can be done if your 
client can somehow query the data stored by your server by other means than 
SIP. But this has nothing to do with the SIP protocol.


Yes there is a way. If the SUBSCRIBE sets the expiration for the 
subscription to 0 then you will get a single NOTIFY and no ongoing 
subscription. (This is standard behavior defined in 3265/6665.)


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] refresher mid-call

[Paul Kyzivat]

On 2/11/15 4:17 PM, rsw2111 wrote:


4028 is clear that the supported header in the initial INVITE indicates
whether or not refreshers are supported by the UAC. In this case, there is
no Supported header in the initial INVITE, so it can be assumed that the
A-side does not support refreshers. That being the case, is the B-side
allowed to sending the Session-Expires: 3700;refresher=uac and Min-SE: 600
in the re-invite?


Note that the scope (duration of applicability) of support indicated by 
a Supported header is not well defined. You cannot assume that it is a 
permanent statement of fact for a device, or even that it applies for 
the duration of a dialog. These things can change midway through a 
dialog. It is certainly applicable for the duration of the request or 
response carrying it, and *probably* applicable for the duration of 
corresponding transaction. Beyond that you can only consider it a hint.


In any case, even if the lack of the Supported:timer did mean that A 
doesn't support it, then B is still permitted to make the request in the 
reINVITE. Assuming the reINVITE did *not* contain Require:timer, then A 
should have simply ignored the Session-Expires and Max-SE headers. If it 
is getting upset by the presence of those particular headers then it 
means it understands them, which implies that it *does* "support" 
session timer. If it is returning 480 because it received a request with 
headers that it doesn't understand at all then it is a very broken SIP 
implementation.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] refresher mid-call

[Paul Kyzivat]

On 2/10/15 4:49 PM, rsw2111 wrote:

Hi,

I've been debating this with someone, and I'd appreciate some outside input.
below is the scenario:

A  B
INVITE ->   with no supported header
<--100
<--18X
<--200OK   with no refresher/session-expires or min-se
ACK >
<--INVITE  with Session-Expires: 3700;refresher=uac and Min-SE: 600
480 ->

We suspect that the re-INVITE is what's causing the 480.


It is hard for me to fathom why 480 is being returned.
What does A expect to happen as a result of this. It is a very bad choice.


my colleague is
under the impression that the B-side re-INVITE should not contain any
refresher since the A-side indicated that they do not support it in the
initial INVITE, and this b-side behavior is non-RFC-compliant .


Failing to explicitly indicate support for an option is *not* an 
indication that the option is unsupported.


As Brett already commented, session timer is renegotiated with every 
reINVITE. A should deal with the reINVITE, and handle it in accord with 
4028. If A doesn't support session timer, then it should ignore the 
Session-Expires and Min-SE headers. You didn't say whether the reINVITE 
had Require:timer. I assume not. If it did, and A doesn't support it, 
then it should have returned a 420 response.


Thanks,
Paul


My understanding is that this is alright as long as they set a min-se and
make themselves the refresher.

This scenario does not seem clear in RFC 4028. can someone please clarify
and provide proof?

Thanks in advance
RSW
___
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] race conditions

[Paul Kyzivat]

On 2/6/15 4:31 AM, Sylvester, Prasanth (NSN - IN/Bangalore) wrote:

Hi Paul,

Thanks for your reply.
For Handling the race conditions, there is already an RFC 5407;


I'm familiar with it. (I'm one of the authors.)


however as per few I've consulted, RFC 5407 doesn't have "Normative" status. 
Does that mean people aren't obliged to follow the RFC?
If this RFC (5407) is to be followed, I see SBC01 isn't behaving that way.


It isn't normative because it doesn't make any changes to existing 
standards - it merely interprets and clarifies what they meant.



Also, sending a BYE before ACK isn't as per RFC 3261;


I didn't mean to suggest sending BYE before ack. Rather, immediately after.

Thanks,
Paul


Sylvester, Prasanth
+91 959 198 7272


-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Paul 
Kyzivat
Sent: Thursday, February 05, 2015 10:02 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] race conditions

On 2/5/15 2:49 AM, Sylvester, Prasanth (NSN - IN/Bangalore) wrote:

Hi Team,

I've a situation,
Customer A -> SBC01 (XYZ vendor) -> SBC02 (XYZ Vendor) -> Core

Customer A sends an invite to SBC01, which reaches to Core. While  Core sends a 200 
OK & before it reaches the Customer A, Customer A had sent a cancel.
Please see the attached pic.

Now the situation is,
1; Customer A sends a cancel to SBC01;
2; SBC01 sends 200 OK back to customer A;
3; SBC01 passes that CANCEL to SBC02;
3; SBC02 sends the 200 OK invite to SBC01.
4; SBC02 sends the 200 OK for cancel to SBC01

Technically, SBC02 has sent a 200OK to invite before it sends 200OK to cancel 
(towards SBC01)
SBC01 has received CANCEL request from A and 200 Ok'd it; Also it had sent 
CANCEL towards SBC02 as well, however it received 200 OK (INVITE) before 200OK 
(CANCEL).

What should be the behavior of SBC01? SBC02? And Customer A?


First, note that this could happen if the SBCs were replaced with
proxies. It is quite possible that there will be a race condition
between the cancel and the invite 200 ok. And that can occur in many
places. The bottom line is that it is not an error for the UAC to send a
cancel, get a 200 ok for the cancel, and then still get a 200 ok to the
invite. It must be prepared for that to happen. In that case it can
choose to either handle the call as if the cancel had never been sent,
or it can send an immediate BYE.

Is that your concern? Or are you explicitly asking if the SBCs may/must
behave differently that proxies would under the same circumstance?

There is not much in the way of explicit rules for SBCs or B2BUAs in
general, other than the the obvious ones that they must behave like a
UAC on one side and a UAS on the other. (And in practice SBCs do lots of
things that don't meet that requirement.)

Also note that CANCEL is "special" among SIP requests, in that it is
handled hop-by-hop rather than end to end. So for handling cancel
proxies and SBCs are much more similar than for other requests.



This is my understanding,

SBC01, it has two roles,
1)  UAS ,While it talks with Customer A. [Case 1]
2)  UAC ,while it talks with SBC02 [Case 2]

Case 1/ SBC01 as UAS - Since SBC01 is "receiving CANCEL & responding 200 OK for the 
cancel" it shouldn't have passed 200OK for the invite (which it received from SBC02) 
towards Customer A;
instead, the behavior should be,
A)  SBC01 should send a 200OK for CANCEL to Customer A(it's doing it)
B)  SBC01 should NOT forward the 200 OK for invite to Customer.
C)  It should send 487 (request terminated) to Customer A.


What you describe is plausible (in this case the SBC is "adding value"
by eliminating the need for Customer A to deal with it). But I don't
think it is *required* to do so. (Because there aren't any rules for
SBCs.) (The 200 to the cancel only says "I received and understood your
cancel". It is then expected to begin the process of acting on it, but
it can take its sweet time in doing so, and might not get around to it
until it sees a response from the other side.)


Case 2/ it's a typical race condition. Where SBC01 has sent a CANCEL to SBC01, 
however SBC02 has send 200OK for invite before sending a 200OK for CANCEL. 
Means, SBC01 has received 200OK for invite first; can be considered as a race 
condition. How to behave in a race condition is mentioned in RFC 5407 (click 
the link below )
https://tools.ietf.org/html/rfc5407#page-13<https://tools.ietf.org/html/rfc5407>
Now, the behavior of SBC01 towards SBC02 should have been,
A)  It should send an A

Re: [Sip-implementors] race conditions

[Paul Kyzivat]

On 2/5/15 2:49 AM, Sylvester, Prasanth (NSN - IN/Bangalore) wrote:

Hi Team,

I've a situation,
Customer A -> SBC01 (XYZ vendor) -> SBC02 (XYZ Vendor) -> Core

Customer A sends an invite to SBC01, which reaches to Core. While  Core sends a 200 
OK & before it reaches the Customer A, Customer A had sent a cancel.
Please see the attached pic.

Now the situation is,
1; Customer A sends a cancel to SBC01;
2; SBC01 sends 200 OK back to customer A;
3; SBC01 passes that CANCEL to SBC02;
3; SBC02 sends the 200 OK invite to SBC01.
4; SBC02 sends the 200 OK for cancel to SBC01

Technically, SBC02 has sent a 200OK to invite before it sends 200OK to cancel 
(towards SBC01)
SBC01 has received CANCEL request from A and 200 Ok'd it; Also it had sent 
CANCEL towards SBC02 as well, however it received 200 OK (INVITE) before 200OK 
(CANCEL).

What should be the behavior of SBC01? SBC02? And Customer A?


First, note that this could happen if the SBCs were replaced with 
proxies. It is quite possible that there will be a race condition 
between the cancel and the invite 200 ok. And that can occur in many 
places. The bottom line is that it is not an error for the UAC to send a 
cancel, get a 200 ok for the cancel, and then still get a 200 ok to the 
invite. It must be prepared for that to happen. In that case it can 
choose to either handle the call as if the cancel had never been sent, 
or it can send an immediate BYE.


Is that your concern? Or are you explicitly asking if the SBCs may/must 
behave differently that proxies would under the same circumstance?


There is not much in the way of explicit rules for SBCs or B2BUAs in 
general, other than the the obvious ones that they must behave like a 
UAC on one side and a UAS on the other. (And in practice SBCs do lots of 
things that don't meet that requirement.)


Also note that CANCEL is "special" among SIP requests, in that it is 
handled hop-by-hop rather than end to end. So for handling cancel 
proxies and SBCs are much more similar than for other requests.




This is my understanding,

SBC01, it has two roles,
1)  UAS ,While it talks with Customer A. [Case 1]
2)  UAC ,while it talks with SBC02 [Case 2]

Case 1/ SBC01 as UAS - Since SBC01 is "receiving CANCEL & responding 200 OK for the 
cancel" it shouldn't have passed 200OK for the invite (which it received from SBC02) 
towards Customer A;
instead, the behavior should be,
A)  SBC01 should send a 200OK for CANCEL to Customer A(it's doing it)
B)  SBC01 should NOT forward the 200 OK for invite to Customer.
C)  It should send 487 (request terminated) to Customer A.


What you describe is plausible (in this case the SBC is "adding value" 
by eliminating the need for Customer A to deal with it). But I don't 
think it is *required* to do so. (Because there aren't any rules for 
SBCs.) (The 200 to the cancel only says "I received and understood your 
cancel". It is then expected to begin the process of acting on it, but 
it can take its sweet time in doing so, and might not get around to it 
until it sees a response from the other side.)



Case 2/ it's a typical race condition. Where SBC01 has sent a CANCEL to SBC01, 
however SBC02 has send 200OK for invite before sending a 200OK for CANCEL. 
Means, SBC01 has received 200OK for invite first; can be considered as a race 
condition. How to behave in a race condition is mentioned in RFC 5407 (click 
the link below )
https://tools.ietf.org/html/rfc5407#page-13
Now, the behavior of SBC01 towards SBC02 should have been,
A)  It should send an ACK to SBC for the 200OK for Invite.
B)  It should send BYE Immediately to SBC (just after ACK).


Again, while it *could* do so, I'm not aware of anything that says it 
must. Some SBCs try to act like proxies most of the time.


What is your goal here? There is nothing that the SBCs can do that will 
totally prevent Customer A from ever seeing a 200 ok to an invite after 
successfully sending a cancel. It MUST remain capable of dealing with that.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] multiple contact header fields in INVITE

[Paul Kyzivat]

On 1/27/15 4:59 PM, Manolis Katsidoniotis wrote:

Hello

I would like to ask if anyone is familiar with multiple entries in Contact
field in INVITE and 200OK messages. I'm looking for implementation examples.


Not permitted.


So far I have seen many examples of multiple contact fields but in 3xx msgs
(300 multiple choices, etc, ...)


Also in REGISTER.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Does Min-Expires in 423 Interval too brief has precedence over 200OK Contact expires?

[Paul Kyzivat]

On 1/22/15 5:54 AM, Brett Tate wrote:

What value the UAC should use in Expires header
on the next REGISTER refresh?


It can basically use whatever it wants.  However if it wants to avoid
potentially receiving another 423, using a value >= last Min-Expires would
be best.


I pragmatically agree with Brett here. But this is a problem caused by 
the SBC. It is behaving perversely, presenting the UAC with an ambiguity.


ISTM that it would be better for the SBC to behave better. It should 
keep the actual expiration time of the registrar to itself, and 
independently manage the expiration time (and Min-Expires) on the leg to 
the UAC.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] many calls contain media IP (0.0.0.0) and Media port as (0).

[Paul Kyzivat]

On 1/18/15 1:07 AM, Imran Saleem wrote:

Dear All,

Can someone please suggest the possible reason for this behavior.

In SBC "The receiving side hooks on before calling party, the line is hold,
the re-Invite changes the stream mode to receive-only and that's why the IP
and port are 0."

What does SIP state..



IP of 0.0.0.0 was the "old" (RFC2543) way of doing hold. The recommended 
way of doing hold was changed to a=sendonly/inactive in RFC3261. But the 
old way is still allowed. Also IP 0.0.0.0 is a way to set up a call (on 
hold) before there are *any* RTP resources assigned to the call.


You should not be upset by this. It is a valid thing to do.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SIP URI syntax vs. generic URI syntax

[Paul Kyzivat]

This seems like a subject that should be taken up on an ietf list. 
sipcore is the likely one, though that is not the place to deal with the 
generic uri syntax.


ISTM that this was a screwup when 3986 was published and didn't address 
backward compatibility with sip URIs.


Thanks,
Paul

On 1/12/15 9:28 AM, Doug Sauder wrote:

Brett, thanks for that helpful reference information.

ISTM that RFC 3986 eliminated the idea of an "opaque" part, so that a
generic
URI has the distinct parts scheme, authority, path, query, and
fragment.  An authority
always starts with "//", so in the generic syntax, a SIP URI has no
authority and
always has a path.

Before the mailto URI was defined, email addresses were commonly written
as john@example.com. *IF* the mailto URI had been defined as
mailto://john@example.com, then the SIP URI probably would have
followed
suit with sip://john@example.com.  In that case, all would be right
with the
world and generic URI syntax.  Too late for that now.

Having said that, I think that "?" and "/" should not be included in the
user
component of a SIP URI, in order to at least somewhat accommodate RFC 3986.
The "?" character delimits the query part, so it should be escaped if it
is not used as
that delimiter.  The "/" could be a problem if it appears as in
sip://john@example.com.  When "//" appears at the beginning, the
generic
parser interprets it as an authority instead of a path.  If "/" is not
allowed in the
user component, then the interpretation of a generic parser would be
consistent for
every SIP URI.

I was not aware of the problem with syntax for IPv6 (discussed in the
thread you
referred to). That's a problem that I think requires changes to RFC 3986.

BTW, as another bit of information on this topic, RFC 6068 (Mailto URI)
has this
to say:

1.  A number of characters that can appear in  MUST be
percent-encoded.  These are the characters that cannot appear in
a URI according to [STD66] as well as "%" (because it is used for
percent-encoding) and all the characters in gen-delims except "@"
and ":" (i.e., "/", "?", "#", "[", and "]").  Of the characters
in sub-delims, at least the following also have to be percent-
encoded: "&", ";", and "=".  Care has to be taken both when
encoding as well as when decoding to make sure these operations
are applied only once.

So perhaps a good SIP implementation should use percent encoding for
"?" and for "//" when it appears at the beginning of a user component.

--
Doug Sauder

On 2015-01-12, 7:18, Brett Tate wrote:

Hi,

And for completeness, RFC 2396 section 3 indicates the following.

"URI that do not make use of the slash "/" character for separating
hierarchical components are considered opaque by the generic URI
parser."

I mention it since some attempt to fit the sip-uri as a hier_part.

absoluteURI   = scheme ":" ( hier_part | opaque_part )
opaque_part   = uric_no_slash *uric



-Original Message-
From: Brett Tate [mailto:br...@broadsoft.com]
Sent: Friday, January 09, 2015 4:10 PM
To: 'Doug Sauder'; 'sip-implementors'
Subject: RE: [Sip-implementors] SIP URI syntax vs. generic URI syntax

Hi Doug,

If I recall correctly, the conclusion of the following thread was that

nobody

cares about fixing any of the existing incompatibilities.

http://www.ietf.org/mail-archive/web/sip/current/msg26318.html

The following email shows why it might be valid (i.e. structured subset

of

opaque_part of RFC 2396 absoluteURI).

http://www.ietf.org/mail-archive/web/sip/current/msg26325.html

The following RFC 2396 section 3.1 snippet may be of interest.

"The URI syntax consists of a sequence of components separated by

reserved

characters, with the first component defining the semantics for the

remainder

of the URI string."



-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Doug Sauder
Sent: Friday, January 09, 2015 2:51 PM
To: sip-implementors
Subject: [Sip-implementors] SIP URI syntax vs. generic URI syntax

The SIP URI syntax in RFC 3261 is not compatible with the generic URI
syntax in RFC 3986.  Specifically, the character "?" should not appear
in the user component. Arguably, the character "/"
also should not appear in the user component.

Surely this topic must have been discussed before now. Does anyone
have information about prior discussions, or other comments on this
topic? Has there been a previous attempt to make the SIP URI syntax
compatible with the generic URI syntax?

Thanks!


___
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-imp

Re: [Sip-implementors] SIP option tags are case sensitive?

[Paul Kyzivat]

On 12/30/14 7:06 AM, isshed wrote:

Hi All,

Could anybody please let me know if the SIP option tags are case sensitive?


No, they are not.

RFC3261, section 7.3.1:

   When comparing header fields, field names are always case-
   insensitive.  Unless otherwise stated in the definition of a
   particular header field, field values, parameter names, and parameter
   values are case-insensitive.  Tokens are always case-insensitive.
   Unless specified otherwise, values expressed as quoted strings are
   case-sensitive.  For example,

And 'option-tag' is defined as a 'token'.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] ReINVITE offer answer failure

[Paul Kyzivat]

On 12/5/14 7:47 AM, ankur bansal wrote:

Hi
Reinvite acting as session modification request here so its behavior
should be atomic.
And reinvite failed in the end reason could be any error response or
offer answer failure.but uac should try to restore session state sending
update request to get session back in sync as recommended in rfc 6337
section 3.4.as <http://3.4.as>


In the case of reINVITE failure with rollback, both ends know that there 
has been a failure, and so both can rollback to the same state.


In this case the UAC believes there has been a failure, but the UAS 
thinks (mistakenly) that there has been success. So the UAS won't be 
rolling back - it will retain whatever that it thinks it should now be 
in. That is a formula for failure.


Certainly the UAC *could* try to recover the session by sending another 
reINVITE. But at this point should it have any confidence in how that 
will turn out?



i believe you didnt get any media failure
for session parameters established with pre reinvite .if there is media
failure then bye can be sent.


BYE can be sent for any reason!


Also would like to understand what made uas to send 200ok no sdp.is
<http://sdp.is> it just misbehaviour or uas sent any 183sdp before.plz
share full call flow to understand uas behaviour in better way


Yes - if there is more to the call flow then we need to see it all to 
really understand.


Thanks,
Paul


On Dec 4, 2014 10:45 PM, "Paul Kyzivat" mailto:pkyzi...@alum.mit.edu>> wrote:

On 12/4/14 2:20 AM, Tarun2 Gupta wrote:

Hi

Our implementation is clearing the call on receiving no SDP
(answer) in 200 OK for a ReINVITE with SDP (offer) sent. Is this
(call clearing) the recommended behavior?
I am not able to find any normative RFC references to support
this. Can you please help here?


Is this a typical simple reINVITE:

-> reINVITE w/SDP (offer)
<- 200 OK without SDP

Or were there some other messages involved?

I agree that if the above is the case, then you are in an
inconsistent state relative to the other UA and it is probably hard
to continue the call.

 Thanks,
 Paul

_
Sip-implementors mailing list
sip-implement...@lists.cs.__columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/__mailman/listinfo/sip-__implementors
<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] ReINVITE offer answer failure

[Paul Kyzivat]

On 12/4/14 2:20 AM, Tarun2 Gupta wrote:

Hi

Our implementation is clearing the call on receiving no SDP (answer) in 200 OK 
for a ReINVITE with SDP (offer) sent. Is this (call clearing) the recommended 
behavior?
I am not able to find any normative RFC references to support this. Can you 
please help here?


Is this a typical simple reINVITE:

-> reINVITE w/SDP (offer)
<- 200 OK without SDP

Or were there some other messages involved?

I agree that if the above is the case, then you are in an inconsistent 
state relative to the other UA and it is probably hard to continue the call.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Inserting PAI header by UA

[Paul Kyzivat]

On 11/20/14 6:41 AM, Rajesh wrote:

Hi,

   May I know whether it is fine if UA insert PAI header in the INVITE
message which it sends to a trusted network entity. I am analysing one
scenario where one of our network node gets a call from another trusted
node with From set to Anonymous and PAI header set to Calling party and
Privacy header set to id.

   After this, this network node creates another out dial call(not in the
same dialogue) in a trusted domain. But this time this network node set
  From to anonymous,  no PAI header but it inserts P-Preferred-Identity
header to calling party and privacy header set to id. Is this the correct
behaviour? Thanks


1. Is it fine for an UA to insert PAI header in the initial INVITE if it
sends a message in a trusted domain
2. Is it fine for an UA to insert PPI header in the initial INVITE if it
sends a message in a trusted domain


It isn't really a question of what the UA is allowed to insert. It it 
more of a matter about what the recipient is willing to believe.


If the receiver trusts the sender, then it may choose to honor a PAI 
that it receives. If it doesn't trust the sender then it probably won't 
honor PAI.


So the UA can insert PAI if it wants. But it should probably consider 
whether it has reason to believe the recipient will trust it before 
doing so.


PPI for use by a UA that isn't within the trust domain, but has 
authenticated with a trusted agent. Then the expectation is that the 
trusted agent (edge proxy) will insert PAI on its behalf before passing 
on to the remainder of the trusted network. When the UA has multiple 
identities that the trusted agent could insert on its behalf it can 
express a preference for which one should be inserted using PPI. (If it 
only has one identity, then PPI probably isn't useful.)


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Clarification Required on section 7.4 RFC 3966

[Paul Kyzivat]

On 11/20/14 1:38 AM, Ambrish Kumar wrote:

Hi All,


We read the RFC 3966 and understood that the global number should be
prefixed with “+” and if it is not prefixed with “+” then it is considered
to be a local number and a phone-context is a MUST.



But the section 7.4 is a bit confusing to the ABNF syntax of global number.

Does it mean that, if the user dials “00” prefix as an example
(“00919840012345”) and it reaches the server without a phone-context, do we
still need to consider it as a global number in the server side..?


I agree with Brett. If the user dialed “00919840012345” then your only 
valid way to form it into tel URI format is to reformat it into global 
number format ("+1919840012345") before sending to the server.


While you could *syntactically* form it into local-number format, such as:

   tel:00919840012345;phone-context=+1

that violates the semantic rule that it must be formatted as a global 
number if that is a valid representation.


If you can't do the global number conversion locally, then you can 
format it as a sip URI in dialstring format [RFC4967]:


   sip:00919840012345;phone-context=+1...@example.com;user=dialstring


If we consider that way, the ABNF syntax is contradicting.

Kindly clarify the section 7.4 RFC 3966:

7.4.  Do Not Confuse Numbers with How They Are Dialed

As an example, in many countries the E.164 number "+1-212-555-3141"
will be dialed  as 00-1-212-555-3141, where the leading "00" is a
prefix for international calls.  (In general, a "+" symbol in E.164
indicates that an international prefix is required.)


This is telling you that dial strings need to be reformatted to put them 
into tel format.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Warning code SRTP

[Paul Kyzivat]

On 11/18/14 1:30 PM, Ilan Avner wrote:

Hi all,
We are now doing some WEB-RTC interop tests with Chrome Browser, we test both 
Audio and Video, currently it looks like Chrome requires SAVPF and while using 
Video Chrome also sends a lot of video retransmissions depending on the control 
RTCP feedbacks, my question is
1. How common is the SAVPF and do you see a need for SBC's to overcome AVP\SAVP 
mismatches
2. Is there a way to work with Chrome\FireFox or any other browser without the 
feedback


There was a discussion of this at IETF last week. I forget now if it was 
in RTCWEB, MMUSIC, or both. Look at the slides in the proceedings.


The fundamental problem is there is a lot of trouble with this proto 
field in the m-line. There are formal rules for what should go there, 
but often implementations don't support those. It is compounded by the 
use of ICE. With ICE, the transport that will be used for the RTP isn't 
known when the offer is sent. It may be UDP or TCP.


Regarding AVP, SAVP, AVPF, SAVPF, I'm not big into RTP, but AFAIK the S 
is for Secure, and the F is for Feedback. For RTCWEB S is required and I 
think F is recommended. But I'm not certain about that.


Again, check the proceedings of IETF91 - RTCWEB and MMUSIC.

Good Luck,


Thanks

Ilan

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Dale R. 
Worley
Sent: Monday, November 17, 2014 8:47 PM
To: Olle E. Johansson
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Warning code SRTP


From: "Olle E. Johansson" 

Which SIP warning code can I use in combination witha  488 response to
indicate that the offer was RTP/SAVP and my UA doesn't support it.


It looks like 302 is the right one.  "RTP/SAVP" is the only media transport 
protocol (a profile of RTP), but the UA can't use it:

   302 Incompatible transport protocol: One or more transport
   protocols described in the session description are not
   available.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors



This email and any files transmitted with it are confidential material. They 
are intended solely for the use of the designated individual or entity to whom 
they are addressed. If the reader of this message is not the intended 
recipient, you are hereby notified that any dissemination, use, distribution or 
copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender 
and delete or destroy any copy of this message
___
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] Query regarding SDP negotiation

[Paul Kyzivat]

On 11/5/14 7:05 AM, Brett Tate wrote:

But my newer question is even by sending BYE for this
flow A is not violating any RFC. Since from the booth
RFCs mentioned above  the expected behavior mentioned
by Ankur is SHOULD way not in MUST. So A behavior
may not the be best one but also not a violation of RFC.

Whether my above conclusion is correct?


Correct.  RFC 3261 section 15 indicates that the caller can send BYE over a
confirmed dialog.  Thus if the caller (or their device) only wants to allow
an answered call to remain for 1 millisecond, that is their prerogative.


Yes, it certainly is.

This is not a standardization issue. It is a quality of implementation 
issue. The customers might not be happy with this behavior.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Ack new transaction as per 3261 but what now after rfc6026

[Paul Kyzivat]

On 11/3/14 7:59 PM, ankur bansal wrote:

Thanks Paul for the answer
But still not clear why ACK needs to be new transaction .Anyway TU only
sending ACK so multiple ACKs can be sent if multiple 200 come.
Do we have any better explanation for this .Also i was thinking if they
changed the 200 transaction handling from transaction terminate to
transaction accepted then at same time they would have made ACK handling
also same for any final response .
But its kept same for some reason which i am trying to understand.


While I have been involved with SIP for a long time, this decision is 
older than that (more than 12 years ago), so I wasn't involved in it. I 
gave you my best understanding of why. At this point there is little 
point is speculating why, because it it too firmly engrained to be changed.



On Fri, Oct 31, 2014 at 10:04 PM, Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote:

On 10/31/14 12:27 PM, ankur bansal wrote:

Hi All

Why ACK is made separate transaction when 2xx is final
response.Reasons
being given that TL is deleted on getting 2xx to be independant of
upperlayer whether its UA core or proxy core.but now after rfc
6026 came TL
not deleted on getting 2xx.then whats the reason to keep ACK
still new
transaction


The simple answer is that when an INVITE is forked, it is possible
to get more than one successful response. Each of those needs to be
ACKed to the proper place.

When the INVITE fails it is considered failed for all forks, and so
you only need one ACK.

 Thanks,
 Paul

_
Sip-implementors mailing list
sip-implement...@lists.cs.__columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/__mailman/listinfo/sip-__implementors
<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] Ack new transaction as per 3261 but what now after rfc6026

[Paul Kyzivat]

On 10/31/14 12:27 PM, ankur bansal wrote:

Hi All

Why ACK is made separate transaction when 2xx is final response.Reasons
being given that TL is deleted on getting 2xx to be independant of
upperlayer whether its UA core or proxy core.but now after rfc 6026 came TL
not deleted on getting 2xx.then whats the reason to keep ACK still new
transaction


The simple answer is that when an INVITE is forked, it is possible to 
get more than one successful response. Each of those needs to be ACKed 
to the proper place.


When the INVITE fails it is considered failed for all forks, and so you 
only need one ACK.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Supported with replaces parameter is Mandatory to support REFER request

[Paul Kyzivat]

On 10/30/14 5:23 PM, Dale R. Worley wrote:

From: Paul Kyzivat 



I disagree here. UA B would be irresponsible if it created an INVITE
including a header field that it doesn't understand.


Why would it be irresponsible?

It's not UA B that's deciding to produce the INVITE, it's the element
that sends the REFER to UA B that is deciding that Replaces is needed.


If UA B understands Replaces, then it will presumably know that it is 
safe to include it in the INVITE - that it is harmless.


But if UA B *doesn't* understand the header, then it doesn't understand 
what the implications are of including it. And the resulting INVITE is 
from B - it will be responsible for whatever happens. Doing that is 
irresponsible.


For instance, what if a Geolocation header was embedded in the URI, and 
UA B didn't understand that header. This could result in UA B making a 
call with a fraudulent location. That could potentially be used for lots 
of ulterior purposes.


A similar but more extreme example of that is a 'method=" parameter in 
the Refer-to URI. If the recipient doesn't understand the method named 
it would be irresponsible (insane) for it to create a request with that 
name.


Thanks,
Paul


And that element is responsible for deciding to what to do if
destination of the INVITE does not understand Replaces -- ignore it
(the default) or reject the INVITE (by also putting
"&Require=replaces" into the Refer-To URI).

Dale



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] call transfer without using REFER

[Paul Kyzivat]

On 10/30/14 2:11 AM, Mahudeswaran A wrote:

Hello All,

Is it possible to transfer a call without using SIP REFER.
Call path:
[uac]---[sip proxy][uas]
The SIP REFER is not supported in the above sip proxy. Is there a way to 
achieve call transfer without using sip refer...


It depends on what you mean. There are some ways that work in restricted 
situations, and with limitations.


For the moment, consider only attended transfers - Alice first calls 
Bob, then Alice calls Charlie, then Alice wants to get out of the call 
and leave Bob talking to Charlie. Some possibilities:


1) Alice does reinvites to Bob and Charlie to broker an offer/answer 
between them so that they end up sending media directly to one another. 
Alice stays in the signaling path but not the media path.


2) Alice stays in the signaling path and media, relaying the media 
between Bob & Charlie.


3) There is an intermediary in the call path (you called it a proxy, but 
it is really a B2BUA.). Alice uses REFER, but the intermediary 
intercepts it, changes it into reinvites. This isn't totally without REFER.


4) similar to (3), but REFER isn't used. In this case there must be some 
form of non-standard signaling between Alice and the intermediary to 
indicate the desire to transfer.


5) a variant of (4): the UA representing Alice isn't really the device 
on her desk. Rather it is a B2BUA (what is somethings called a SIP PBX.) 
The device on Alice's desk may be a SIP UA, but it is treated as a dumb 
slave device controlled by the B2BUA. Feature signaling from Alice's 
device to the B2BUA may be propretary, or might be DTMF over SIP. The 
B2BUA can then use reinvite to handle transfers.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Supported with replaces parameter is Mandatory to support REFER request

[Paul Kyzivat]

On 10/28/14 11:54 AM, Dale R. Worley wrote:

From: Sourav Dhar Chaudhuri 

 Actually my scenario is attended call transfer using REFER
 method. So here I want to transfer an  attended call using
 REFER method. But the  User agent B whom I want to send REFER
 request with the existing dialog information  does not having
 Support for replaces header. So in that case how does the User
 agent B will behave when it  will receive the REFER request
 which is having existing Dialog information in that Refer to
 header with replaces parameter?


There is some subtlty to the correct answer:

"you" send a REFER request to User Agent B.  The Refer-To value in the
REFER request contains a "replaces" "header parameter" (called
"header" in RFC 3261 section 25.1).  The result of this header
parameter is that the INVITE that User Agent B generates will contain
a Replaces header field.

This behavior is *not* dependent on whether User Agent B implements
"replaces".  The fact that UA B generates an INVITE is required by RFC
3515 section 2.4.3.  The INVITE must be generated using the Refer-To
URI.

But the process of creating the INVITE from the URI is defined in RFC
3261 section 19.1.1 (among others) and it requires that *all* header
parameters in the URI are used to construct header fields in the
INVITE.  (Excepting for certain header names that are known to be
"dangerous".)  UA B must create the Replaces header field regardless
of whether it understands or implements Replaces headers itself.


I disagree here. UA B would be irresponsible if it created an INVITE 
including a header field that it doesn't understand.


Thanks,
Paul


Of course, for the attended call transfer to complete successfully,
the UA which *receives* the INVITE must implement Replaces.

One further consideration:  If the other UA does not implement
Replaces, the best user experience is obtained if the other UA rejects
the INVITE -- otherwise, the user at that UA receives what appears to
be an additional incoming call.  So it is desirable for the generated
INVITE to contain the header field "Require: replaces".  This can be
accomplished by adjusting the Refer-To URI in the REFER request:

 Refer-To: sip:user@host?Replaces=&Require=replaces

Dale
___
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] c= line for disabled media streams

[Paul Kyzivat]

On 10/23/14 4:28 AM, Saúl Ibarra Corretgé wrote:


Thank you all for the comments!

Adding a c= line is not an actual problem, I just wanted to know if it was 
necessary or not :-)

Out of curiosity, what purpose does it serve if a disabled stream? One can 
surely add it back wen re-enablinkg it…


It doesn't serve any great obvious need, other than to satisfy the 
letter of the specification as written.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] c= line for disabled media streams

[Paul Kyzivat]

On 10/22/14 11:37 AM, Saúl Ibarra Corretgé wrote:

Hi all,

I recently ran into an intro issue with some unknown SIP device. My client uses 
a per-stream SDP connection line, but when a stream is disabled (port set to 0) 
the stream is just reduced to the m= line.

Technically I could put the connection line at the session level in some cases, 
but it could be that I need to have it at the stream level. Should I also add 
it for disabled streams? FWIW, doing so made the aforementioned SIP device 
happy, but I couldn’t find any RFC reference which stated it’s always required.

Any clarification (or recommendation) would be appreciated, thanks!


As others have commented, I think you MUST have *some* c-line for each 
m-line, whether disabled or not.


If it makes your logic simpler, you could *always* have a token c-line 
(e.g., "c=IN IP4 0.0.0.0") at the session level, and then a separate 
c-line for each non-disabled m-line.


Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] can CRBT palyed without Reliable Provisonal response.

[Paul Kyzivat]

On 10/15/14 12:16 PM, Mustafa AYDIN wrote:

Hi Vivek,

I agree most of your comment, however considering that the question here
is “can CRBT palyed without Reliable Provisonal response.” and due to
the fact that CRBT is an actually an _early media RTP flow_  (played
before 200 OK), there is nothing to prevent UAC to get the CRBT in this
scenario  as the UAS knows where to send RTP. There should not be a
  dependency to  the client as it is totally  as per RFC.


Yes, the caller should get the early media. The problem is with the 200 
with a new offer. So the caller may not get the final media.


But your issue is that the caller isn't getting the early media???

If so, maybe it is something else. For instance, it is pretty common to 
gate the incoming media - requiring that it come from the IP 
address/port in the answer. Maybe the media isn't being sent that way.


Thanks,
Paul


Regards,

Mustafa Aydın

NGN Services

Verscom Solutions

cid:image002.png@01CFD749.D928FC00

*From:*Vivek Talwar [mailto:vivek.tal...@globallogic.com]
*Sent:* Wednesday, October 15, 2014 6:31 PM
*To:* Mustafa AYDIN
*Cc:* Paul Kyzivat; sip-implementors@lists.cs.columbia.edu
*Subject:* Re: [Sip-implementors] can CRBT palyed without Reliable
Provisonal response.

Hi Sourav,

 The UAS cann't send new offer in initial INVITE as per
standards. Although above scenario can be propitiatory where sdp in 200
OK can be treated as answer but again as per standards sdp should be
same in 1xx and 2xx responses. This will depend on client but yes above
can work in some cases as B knows where to send media packets.

Thanks and Regards,
Vivek Talwar

On Wed, Oct 15, 2014 at 8:21 PM, Mustafa AYDIN
mailto:mustafa.ay...@verscom.com>> wrote:

Phil,

I agree the messaging after 200 ok is incorrect but the main question is
with the CRBT which is sent before 200 ok. Why do u think that the
client would not get early media if the sdp in INV is correct ?

Rgrda
Mustafa

From: sip-implementors-boun...@lists.cs.columbia.edu
<mailto:sip-implementors-boun...@lists.cs.columbia.edu>
[sip-implementors-boun...@lists.cs.columbia.edu
<mailto:sip-implementors-boun...@lists.cs.columbia.edu>] On Behalf Of
Paul Kyzivat [pkyzi...@alum.mit.edu <mailto:pkyzi...@alum.mit.edu>]
Sent: Wednesday, October 15, 2014 5:47 PM
To: sip-implementors@lists.cs.columbia.edu
<mailto:sip-implementors@lists.cs.columbia.edu>
Subject: Re: [Sip-implementors] can CRBT palyed without Reliable
Provisonal response.

On 10/15/14 10:22 AM, Sourav Dhar Chaudhuri wrote:
 > Hi,
 >  Can CRBT works without using Reliable Provisional Response ?
 >
 >
 >
 > A      INVITE (with SDP offer)
>  B
 >
 > A  <===   180 ringing (with SDP answer )
   B  --> It is not a RPR
 >
 >   CRBT  Played
 >
 > A  <=== 200 OK for INVITE  ( new SDP offer)
===B
 >
 > A  =   ACK(new SDP answer)
  ===>   B
 >
 >
 > Whether the above diagram is a correct call flow for CRBT without
using Reliable Provisional response?

This is not correct, and wouldn't be correct even if the 180 was reliable.

See RFC6337.

 Thanks,
 Paul

 > Regards
 >
 > Sourav Dhar Chaudhuri
 > ___
 > Sip-implementors mailing list
 > Sip-implementors@lists.cs.columbia.edu
<mailto: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
<mailto: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
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors




--

*Name | Title*
GlobalLogic
P +x.xxx.xxx.  M +x.xxx.xxx.  S skype
www.globallogic.com <http://www.globallogic.com/>

http://www.globallogic.com/email_disclaimer.txt



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] can CRBT palyed without Reliable Provisonal response.

[Paul Kyzivat]

On 10/15/14 10:22 AM, Sourav Dhar Chaudhuri wrote:

Hi,
 Can CRBT works without using Reliable Provisional Response ?



A      INVITE (with SDP offer)  >  B

A  <===   180 ringing (with SDP answer )    B  
--> It is not a RPR

  CRBT  Played

A  <=== 200 OK for INVITE  ( new SDP offer) ===B

A  =   ACK(new SDP answer)   ===>   B


Whether the above diagram is a correct call flow for CRBT without using 
Reliable Provisional response?


This is not correct, and wouldn't be correct even if the 180 was reliable.

See RFC6337.

Thanks,
Paul


Regards

Sourav Dhar Chaudhuri
___
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] SUBSCRIBE 200 & NOTIFY out of order.

[Paul Kyzivat]

On 10/1/14 9:08 AM, Kumar, Puneet (Puneet) wrote:

Hi All,

Consider following use case:

UA1 Proxy   UA2
SUBSCRIBE>
--SUBSCRIBE->
   <--200---
   <---NOTIFY--
<---NOTIFY--
<---200---


As seen above UA1 Subscribe to UA2 for an event through Proxy server.
UA2 accepts this subscribe & respond with a 200 followed by a NOTIFY to 
indicate current status of the event.
But somehow proxy send the NOTIFY first to UA1 followed by 200 for SUBSCRIBE.

As per section 3.1.4.4 on RFC 3265 above behavior on UA1 is allowed.

Currently UA1 ignores this NOTIFY as it always expected NOTIFY after 
200(SUBSCRIBE)
What should UA1 do so that it can handle this message mismatch properly?

If UA2 receive some 4xx response for NOTIFY with a retry-after header will it 
retry NOTIFY?


Maybe, if you are lucky.

I presume you are talking about a case where all of these are following 
RFC3265, rather than RFC6665?


The way UA1 is supposed to behave is:

- the subscribe has a to-tag but no from-tag.
- after sending the subscribe, UA1 has a pending dialog
  awaiting complete establishment when the from-tag becomes known
- the notify will have the from-tag and call-id from the invite,
  plus a to-tag assigned by UA2
- UA1 should try to match the (from-tag,call-id,to-tag) of the
  notify against existing established dialogs. This will fail.
- then (special case for notify), UA1 should try to match the
  (from-tag,call-id) against pending dialogs. This will succeed.
- UA1 marks the pending dialog complete, filling in the to-tag.
  (You can make the assumption here that the subscribe will
  eventually succeed.)
- UA1 goes ahead and processes the notify.
- later the 2xx for the invite arrives. UA1 successfully matches
  this against existing established dialogs, and processes it.

RFC6665 clarifies this behavior and tweaks it some.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] UAS behaviour for sending responses

[Paul Kyzivat]

On 9/19/14 1:20 PM, Kchitiz Saxena wrote:

Hi Brett
There is no received parameter in the request. Below is the Via header I
can see in the pcap taken at UAS -


Note that the message, as received by the UAS, won't contain a 
"received" parameter. The UAS itself adds this parameter, and then 
consumes it when generating responses.


So possibly your device isn't doing this.

Thanks,
Paul


Via:SIP/2.0/UDP XX.YYY..net
;branch=z9hG4bKBW.-tsom1l-91.230.17.136V5060-0-107949759-1337557677-142656253-

When UAS resolves XX.YYY., it receives IP address B at top, the source
IP address (A) of the INVITE request is also present but that is after IP
address B.

On Fri, Sep 19, 2014 at 7:34 PM, Brett Tate  wrote:


Hi Kchitiz,

Concerning your question, you skipped the first part of section 18.2.2
bullet 3 (assuming UDP).  If first part of bullet 3 is successful, the UAS
does not need to resolve the sent-by FQDN.

 o  Otherwise (for unreliable unicast transports), if the top Via
has a "received" parameter, the response MUST be sent to the
address in the "received" parameter, using the port indicated
in the "sent-by" value, or using port 5060 if none is specified
explicitly.  If this fails, for example, elicits an ICMP "port
unreachable" response, the procedures of Section 5 of [4]
SHOULD be used to determine where to send the response.

-

From: Kchitiz Saxena [mailto:kchitiz.sax...@gmail.com]
Sent: Friday, September 19, 2014 9:49 AM
To: Brett Tate
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] UAS behaviour for sending responses

Hi Brett
Thanks for the reply, can you please clarify it a bit more.

Yes, there is no maddr in Via header received. When UAS resolves FQDN
mentioned in Via header, it receives the "other"(Looks like UAC has 2
entries in DNS server for this hostname) IP address at top. Hence it sends
responses back to the other address. Do you mean that UAS should somehow
send responses to both addresses received in DNS reply? UAC is not
accepting
responses at "other" IP.

Thanks
Kchitiz


___
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] Call transfer for an attended call without using REFER method possible?

[Paul Kyzivat]

On 8/11/14 12:33 AM, Arun Tagare wrote:

Hi Paul,

According to your response as below.
"It is also possible for Alice to use 3pcc O/A techniques to establish a
direct *media* path between Bob and Charlie, while Alice remains in the
signaling path between them"

While Alice remains in the signaling path means it is some thing like
"Conference Call you are talking about"
Correct me if i am wrong.


That depends on what you mean by "some thing like". :-)

You can think of it as a conference hosted by Alice, but where Alice is 
muted. Because Alice is muted there is no need for "mixing" of the media 
- it is sufficient to "switch" the media. So it is a lower cost operation.


Thanks,
Paul


Thank you,

With Regards
Arun A. Tagare




On Wed, Aug 6, 2014 at 12:30 AM, Sourav Dhar Chaudhuri
mailto:sourav_mi...@yahoo.co.in>> wrote:

Hi Paul,
Thanks a lot for your detailed response. You have answered all
my doubts.

   I am really grateful for your email.

Thanks & Regards,
Sourav Dhar Chaudhuri



On Tuesday, 5 August 2014 8:11 PM, Paul Kyzivat
mailto:pkyzi...@alum.mit.edu>> wrote:



On 8/4/14 10:12 AM, Sourav Dhar Chaudhuri wrote:
 > Hi,
 > Is there any way when a answered call  [ 200OK is already
provided for initial INVITE and ACK also sent] can be transferred
without using REFER method?
 >
 >If it is possible without REFER then please let me know
required procedure.

More detail is needed to answer this.

Lets assume that Alice and Bob are in a call. You want a transfer, so
let's assume the transfer target is Charlie.

Further, assume it is Alice that wants to initiate the transfer,
resulting ultimately in Bob talking to Charlie.

A simple answer to your question is for Alice to initiate the call to
Charlie, and then bridge the media between Bob and Charlie. It is also
possible for Alice to use 3pcc O/A techniques to establish a direct
*media* path between Bob and Charlie, while Alice remains in the
signaling path between them.

The reason for REFER is to get Alice out of the signaling path. If there
is a middlebox in the signaling (e.g. a sip pbx or an SBC) then in
principle Alice can ask that middlebox to handle the transfer. But Alice
needs a way to convey the desire to do so. Often REFER is still used for
that, but is intercepted by middlebox, which then uses mechanisms such
as I described above. Some other mechanism, other than REFER, can be
used for that but it will be a proprietary solution.

 Does that help?
 Paul




___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto: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
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors




--

With Regards

Arun A. Tagare
+91 9449 029729


___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Call transfer for an attended call without using REFER method possible?

[Paul Kyzivat]

On 8/4/14 10:12 AM, Sourav Dhar Chaudhuri wrote:

Hi,
Is there any way when a answered call  [ 200OK is already provided for 
initial INVITE and ACK also sent] can be transferred without using REFER method?

   If it is possible without REFER then please let me know required procedure.


More detail is needed to answer this.

Lets assume that Alice and Bob are in a call. You want a transfer, so 
let's assume the transfer target is Charlie.


Further, assume it is Alice that wants to initiate the transfer, 
resulting ultimately in Bob talking to Charlie.


A simple answer to your question is for Alice to initiate the call to 
Charlie, and then bridge the media between Bob and Charlie. It is also 
possible for Alice to use 3pcc O/A techniques to establish a direct 
*media* path between Bob and Charlie, while Alice remains in the 
signaling path between them.


The reason for REFER is to get Alice out of the signaling path. If there 
is a middlebox in the signaling (e.g. a sip pbx or an SBC) then in 
principle Alice can ask that middlebox to handle the transfer. But Alice 
needs a way to convey the desire to do so. Often REFER is still used for 
that, but is intercepted by middlebox, which then uses mechanisms such 
as I described above. Some other mechanism, other than REFER, can be 
used for that but it will be a proprietary solution.


Does that help?
Paul



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Sip-implementors Digest, Vol 5, Issue 20

[Paul Kyzivat]

On 7/22/14 6:38 AM, Sunil P wrote:

Hi Paul,

   Wrong P-Asserted Identity means  the one which was not in the
list of P-Associated URI.I am not sure
whether to send 403 since i couldn't get the reference of exact behavior
in the RFC.


This is really an IMS question, so I'm not an ideal person to answer.

You have presented this as a question from the perspective of the 
P-CSCF. But you didn't say *which* P-CSCF - that of the originator, or 
of the target of the request? Or are they the same in this case?


ISTM that this is first and foremost an error on the part of the 
originating P-CSCF. It should not have let this pass. IIUC, the proper 
sequence is that the originating UE inserts a *P-Preferred-Identity* 
header, not P-Asserted-Identity. I think the P-CSCF should filter out 
any P-Asserted-Identity headers, unless it can verify that they are 
correct, because once the request is within the trust domain those 
P-Asserted-Identity headers will be trusted. It could either just remove 
those bogus headers or reject the request.


If somehow that doesn't happen, then the originating P-CSCF should 
probably validate the validity of any received P-Asserted-Identity 
headers and either remove them or reject the request. This is all before 
any consideration of what sort of request this is or what the 
destination is.


After that, when the request reaches the terminating P-CSCF (even if 
that is the same as the originating P-CSCF) the P-Asserted-Identity 
headers may be trusted. At this point it becomes an authorization 
decision - is this requesting identity *authorized* to make this 
request. That is a different sort of decision.


Thanks,
Paul


Thanks and Regards,
Sunil



Message: 2
Date: Sun, 20 Jul 2014 14:35:30 -0400
    From: Paul Kyzivat mailto:pkyzi...@alum.mit.edu>>
To: sip-implementors@lists.cs.columbia.edu
<mailto:sip-implementors@lists.cs.columbia.edu>
Subject: Re: [Sip-implementors] Wrong P-Asserted Identity in Subscribe
 Message to CSCF
Message-ID: <53cc0bf2.4090...@alum.mit.edu
<mailto:53cc0bf2.4090...@alum.mit.edu>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Sunil,

What do you mean by "wrong"?

This is used with transitive trust, so presumably you should trust the
sender to have asserted the correct identity of the sender.

Do you mean that this identity is not authorized to make the
subscription it is requesting? If so, then I guess the proper response
is 403 Forbidden.

 Thanks,
 Paul

On 7/20/14 2:07 PM, Sunil P wrote:
 > Hi All,
 >
 >  What should be the behavior of  CSCF if it receives
Subscribe
 > request from UE
 > with wrong P-Asserted Identity header?.
 >
 > Thanks and Regards,
 > Sunil
 > ___
 > Sip-implementors mailing list
 > Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
 > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
 >



--

Message: 3
Date: Mon, 21 Jul 2014 09:17:44 +0800
From: "=?gb18030?B?U2FtbWFu?=" mailto:yongguang...@foxmail.com>>
To: "=?gb18030?B?TmVlbGFrYW50YW4sIE5lZWw=?="
 mailto:nneelakan...@sonusnet.com>>, "=?gb18030?B?UHJha2FzaCBL?="
 mailto:prakash12...@gmail.com>>,

"=?gb18030?B?c2lwLWltcGxlbWVudG9yc0BsaXN0cy5jcy5jb2x1bWJpYS5lZHU=?="
 mailto:Sip-implementors@lists.cs.columbia.edu>>
Subject: Re: [Sip-implementors] Message Body in ACK other than SDP
Message-ID: mailto:tencent_303793e058988b9429852...@qq.com>>
Content-Type: text/plain;   charset="gb18030"

please Refer to RFC3264




-- Original --
From: "Neelakantan, Neel"mailto:nneelakan...@sonusnet.com>>;
Date: 2014?7?18?(???) ??11:19
To: "Prakash K"mailto:prakash12...@gmail.com>>;
"sip-implementors@lists.cs.columbia.edu

<mailto:sip-implementors@lists.cs.columbia.edu>"mailto:Sip-implementors@lists.cs.columbia.edu>>;
Subject: Re: [Sip-implementors] Message Body in ACK other than SDP



The ACK can have a message body, if the Offer/Answer is done in 200
OK/ACK.  The offer/answer can have multipart-mime message body.  In
that case, ACK can have multipart-mime body (with embedded SDP).

Thanks,
Neel.


 > -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
<mailto:sip-implementors-boun...@lists.cs.columbia.edu> [mailto:sip-
<mailto:sip->
> implementors-boun...@lists.cs.columbia.edu
<mailto:implementors-boun...@li

Re: [Sip-implementors] Wrong P-Asserted Identity in Subscribe Message to CSCF

[Paul Kyzivat]

Sunil,

What do you mean by "wrong"?

This is used with transitive trust, so presumably you should trust the 
sender to have asserted the correct identity of the sender.


Do you mean that this identity is not authorized to make the 
subscription it is requesting? If so, then I guess the proper response 
is 403 Forbidden.


Thanks,
Paul

On 7/20/14 2:07 PM, Sunil P wrote:

Hi All,

 What should be the behavior of  CSCF if it receives Subscribe
request from UE
with wrong P-Asserted Identity header?.

Thanks and Regards,
Sunil
___
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] Cancelling a request

[Paul Kyzivat]

On 7/15/14 7:07 AM, Brett Tate wrote:

Can there be any case when CANCEL reached to UA2
before INVITE in case od UDP? because the 100 trying
can be sent by proxies as well.


Yes, 100 is sent hop by hop. But CANCEL is itself also hop by hop. So at 
each hop the cancel is only sent if a 1xx has been received from downstream.



Yes (although no longer as common); as mentioned within RFC 3261 section
28.1, RFC 2543 did not have the same mandate as RFC 3261.

"o  A UA or proxy cannot send CANCEL for a transaction until it gets a
 provisional response for the request.  This was allowed in RFC
 2543 but leads to potential race conditions."


I guess Brett is saying that it can only happen if there is a device on 
the path that supports 2543 and not 3261. I hope there are no longer any 
of those deployed.


Thanks,
Paul



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Hostnames vs IP Addresses

[Paul Kyzivat]

On 7/14/14 7:47 PM, James Cloos wrote:

"PK" == Paul Kyzivat  writes:


PK> If you give out only URIs with domain names, then that is what
PK> clients should be using.

PK> Only servers that are "responsible for the domain" are permitted to
PK> translate those URIs.

Thanks.  That is what I expected when I wrote the validation code, but I
do not have access to enough different client software to be certain.

PK> Common practice has developed that servers are free to manipulate any
PK> URI that appears to include a phone number, replacing the domain name
PK> as they see fit.

PK> IMO this is *wrong*, but I haven't been able to convince anybody else
PK> of that.

So, if someone were to dial tel:+878107472467264, and their client did
the NAPTR on e164.arpa and found sip:7472467...@jhcloos.com, either
followed that by an NAPTR on jhcloos.com or directly looked for a sip
SRV there, then even though the invite to the proxy SHOULD be to
7472467...@jhcloos.com it might end up being to 7472467264@PROXY_NAME
or to 7472467264@PROXY_IP?  But sip:cl...@jhcloos.com always will
have that string in the invite?


AFAIK that scenario is entirely hypothetical, because public enum has 
been a failure. Carriers use enum, but they do so with private enum DBs 
and peering relationships that determine how they interface with one 
another.


That world is ruled by SBCs. For the most part they keep remapping 
numbers, changing the domain name as the request moves from peer to peer.


But if you were in such a situation, then you probably would know the 
rules they play by and wouldn't be surprised.


Thanks,
Paul

Thanks,
Paul

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] in SDP

[Paul Kyzivat]

On 7/14/14 7:06 PM, NK wrote:

Hi Paul,

Thanks!!. Yes i checked 3264 and it says it should be increment by 1.

However i am more concerned that if there is re invite and in 200 OK
SDP(in the correspondence of re-invite) there is no change as compare to
previous SDP then also  should increment by 1?


In this case you certainly may use the same version.

It is less clear if it is valid to increase the version number when the 
SDP is not changed. If you MUST NOT increment in this case then you are 
obligated to keep track whether it is changed or not, and that may not 
always be convenient.


IMO it is not an error to increment when there has been no change. But 
others may not agree.


Frankly I think having version number indicate there has been no change 
is silly. No experienced programmer will trust this to be correct.


Thanks,
Paul


Regards,
Nitin Kapoor


On Mon, Jul 14, 2014 at 7:02 PM, Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote:

On 7/14/14 6:14 PM, NK wrote:

Dear All,

I have query regarding the Session version in SDP. I know if we
are making
any changes in SDP then from 183 to 200OK with SDP then there
will be
increment in session version from 183  to
200 OK
.  However i have 2 doubt as below. Can you
please help
me on this.

1) Is that Value should be increment by 1  only? I mean suppose
in 183
w/SDP we have Session Version =1 , then is that mandatory that
we should
have "session-version=2" or it can be 3 directly. OR

2) if in 183 w/SDP and 200 Ok we had the same value but when
"re-invite
happened then SDP was same but "session-version" value
incremented from 1
==>3 directly. I feel it should be 2 (i mean increment by 1
only). Please
advise if my understanding is correct.


RFC 3264 requires that it be incremented by 1. But if you are on the
receiving side I suggest you be lenient about this.

 Thanks,
 Paul

_
Sip-implementors mailing list
sip-implement...@lists.cs.__columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/__mailman/listinfo/sip-__implementors
<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] in SDP

[Paul Kyzivat]

On 7/14/14 6:14 PM, NK wrote:

Dear All,

I have query regarding the Session version in SDP. I know if we are making
any changes in SDP then from 183 to 200OK with SDP then there will be
increment in session version from 183  to 200 OK
.  However i have 2 doubt as below. Can you please help
me on this.

1) Is that Value should be increment by 1  only? I mean suppose in 183
w/SDP we have Session Version =1 , then is that mandatory that we should
have "session-version=2" or it can be 3 directly. OR

2) if in 183 w/SDP and 200 Ok we had the same value but when "re-invite
happened then SDP was same but "session-version" value incremented from 1
==>3 directly. I feel it should be 2 (i mean increment by 1 only). Please
advise if my understanding is correct.


RFC 3264 requires that it be incremented by 1. But if you are on the 
receiving side I suggest you be lenient about this.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Hostnames vs IP Addresses

[Paul Kyzivat]

On 7/13/14 8:46 PM, James Cloos wrote:

I've noticed that all of the fraud attempts which come to my advertized
SRV destinations use ip addresses for the To and From headers and for the
INVITE line.

My code to verify that INVITEd addresses are valid expects domain names
or hostnames, not ip addresses in those fields.

Do any legitimate sip connections, after looking up NAPTR and/or SRV
records, use the SRV destinations' addresses in the INVITE attempt?
Or always the string from the sip: uri?

As NAPTR-advertized SRV targets, they have to accept SIP from
everywhere, but like an MX only pass on legitimate-looking calls
and refuse the rest.


How are clients obtaining URIs that reference your destinations? In 
principle, the URIs that identify your destinations are strictly your 
business. If you give out only URIs with domain names, then that is what 
clients should be using. Only servers that are "responsible for the 
domain" are permitted to translate those URIs.


So, if you only hand out URIs with domain names, you should feel free to 
reject requests where the R-URI has your IP address.


Do your URIs contain names, or phone numbers in the user part?

Common practice has developed that servers are free to manipulate any 
URI that appears to include a phone number, replacing the domain name as 
they see fit.


IMO this is *wrong*, but I haven't been able to convince anybody else of 
that.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Tel URI having escape sequence in it

[Paul Kyzivat]

On 7/7/14 6:23 AM, Jatin Kohli wrote:

Hi All

What should be the behavior of a SIP parser while decoding a To header having  
tel URI with escape sequence in it ?

Example:
To: ;tag=6348SIPpTag012



Is the above tel URI valid (wrt both RFCs 2806 and RFC 3966)?


According to 3261 the tel URI must first match the syntax addr-spec. It 
does, because it matches absoluteURI, containing an opaque-part, which 
allows the escaping. So far so good.


The next question is whether the escaping is to be replaced, according 
to the sip defined mapping, before being reparsed according to its own 
scheme syntax, or if the intent is simply to leave the escaping still in 
place and parse it according to its scheme.


AFAIK there is nothing that really says, one way or the other. But since 
escaping is intended to work around cases where you need to include 
characters that sip doesn't otherwise allow, and since the target scheme 
syntaxes can't have anticipated that, I think it only makes sense that 
the escaping *is* replaced before reparsing.


Assuming that, then the uri becomes: 
. This is valid according to 
3966. It is not valid according to 2806 because that rfc doesn't allow 
an fqdn as a phone-context. (It doesn't allow ".", and not all of the 
alphabet. I have no idea what it was trying to do.)



What should be the behavior of a SIP parser on receipt of such a message?


Depends on whether you are processing the tel uri according the 3966 or 
2806.


If you use 2806 and consider this invalid, then you can do as you wish. 
You could ignore the error, since it is just the To-URI and that doesn't 
necessarily affect anything.


If you want to reject it, then 400 is probably the response that best 
reflects the problem.


If you attempt to continue processing the request, then you may 
encounter additional errors if you don't "understand" this number. You 
might end up wanting to return 404 Not Found. But that would be more 
likely if this were in the R-URI. You really shouldn't be trying to find 
the To-URI.


Thanks,
Paul



Thanks and regards
Jatin Kohli


"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the 
use of the individual to whom it is addressed. It may contain privileged or confidential 
information and should not be circulated or used for any purpose other than for what it 
is intended. If you have received this message in error, please notify the originator 
immediately. If you are not the intended recipient, you are notified that you are 
strictly prohibited from using, copying, altering, or disclosing the contents of this 
message. Aricent accepts no responsibility for loss or damage arising from the use of the 
information transmitted by this email including damage from virus."
___
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] Anonymous URI in SIP PAI header

[Paul Kyzivat]

Is is silly and inappropriate to assert the validity of 
anonymous@anonymous.invalid, because there is no such domain. Hence 
nobody is in a position to make such an assertion.


But it could be appropriate to assert sip:anonymous@somedomain. This 
would presumably mean: this is from *some* valid user of somedomain, but 
which one is being withheld. This has more utility in domains with many 
users than in those with just a few.


This has even been discussed in the ongoing work in the ietf STIR wg.

Thanks,
Paul

On 7/2/14 12:30 PM, Joel Gerber wrote:

It's valid, but more than slightly silly. Why even send a PAID if it's not 
going to have valid information?

For PPID, it still would be valid, but pretty much guaranteed that it will be 
ignored.

Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Rajesh
Sent: July-02-14 12:17 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Anonymous URI in SIP PAI header

Hi,

   May i know whether it is valid to add Anonymous URI (
anonymous@anonymous.invalid) in the PAI (P-Asserted-Identity) header filed.
Thanks

Regards
Rajesh
___
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



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Difference Between SIP registration & reregistration

[Paul Kyzivat]

On 7/1/14 11:11 AM, Sourav Dhar Chaudhuri wrote:

Hi Paul,
  At first thanks a lot for your very fast response. Actually I am
verifying a Registrer behavior with those kinds of REGISTER request.

  As you mentioned for my first scenario that the Binding will be
changed. Whether that will consider as New Registration request or
reregistration?


What difference does it make?

The binding will remain. The callid and cseq associated with it will change.


 Also by reading your explanation, if a REGISTER request is having
same call ID with previous any REGISTER request  and also sent before
the expiry of the that previous REGISTER request, moreover it has higher
CSeq value than the previous REGISTER  request.  Then that second
REGISTER request is considered as a reregistration.

In any other case is possible where any REGISTER request will be
considered as  reregistration ?


Again, what distinction are you trying to draw?

All the matters are externally discernible changes in behavior.

Are you concerned with GRUUs, or with the "reg" event package?
If not, then there is no observable difference.


  Actual I am asking reregistration terminology  specifically due to
Authorization implementation for reregistration.


I don't understand. Do you mean that there is some authorization policy 
that is different for reregistration than for initial registration?


Thanks,
Paul


Thanks & Regards

Sourav Dhar Chaudhuri


.
On Tuesday, 1 July 2014 7:53 PM, Paul Kyzivat  wrote:


On 7/1/14 9:37 AM, Sourav Dhar Chaudhuri wrote:
 > Hi,
 >  How can be determined that whether SIP REGISTER is for new
registration or reregistration by seeing the request.

You *can't* tell by examining the REGISTER.
And for the most part it doesn't matter.

 >It seems that in case if the CSeq header value is considered then
we can found something.  So please find my question

The sender of REGISTER is required to increment the CSeq for each
REGISTER with the same Call-ID. The registrar is required to retain the
call-id and cseq used to establish each binding. Look at bullet 6 of
section 10.3 of 3261.

 > i) First Scenario
 > a) Consider an UE very first time sent REGISTER request with CSeq
value as : 55 with one contact. Call-ID: 123 with expires 60
 >b)  It got successfully registered.
 >c) Now with 50  seconds  UE sends second REGISTER request with
CSeq value as 40 with same contact . different Call ID 456 [Whether CSeq
value has to be increased since call ID is different]
 >
 >but still with this behavior whether Second Register will be
entertained?

Above is valid. The binding is replaced.

 > ii) Second Scenario:
 >  a) UE very first time sent REGISTER request with CSeq value as :
55 with Expiry = 60 and Call-Id: 345 with one contact
 >  b)  It got successfully registered. This registration will be
over after 60 seconds
 >
 >  c)  After 120 seconds

So binding has expired.

 UE sends second  REGISTER request with CSeq value as 70 and
different Call-Id: 789 with same contact . How second REGISTER will be
differentiated with new registration or reregistration.

This is valid as a new registration. So the binding was present, then
absent, then present again.

 > iii) Third Scenario:


 >  a) UE very first time sent REGISTER request with CSeq value as :
55 with Expiry = 60 and Call-Id: 876 with one contact
 >  b)  It got successfully registered.
 >
 >  c) within 50 seconds UE sends second  REGISTER request with CSeq
value as 70 and different Call-Id: 321 with same contact with Expiry = 0
. Whether UE will be deregistered?

Yes. The new registration is valid, replacing the old one, and then
immediately expiring.

In the normal case where you establish a registration and then attempt
to maintain it by refreshing before it expires, it may be possible that
your refresh will be "late". If it arrives on time then it is a refresh,
and if it arrives late then it is a new registration.

And you can do that using the same call-id or different ones. You SHOULD
do it using the same call-id. If you use the same call-id then you must
use increasing cseq values. That helps to detect screw ups, because they
will be rejected.

Of course, during the period when your registration was expired you may
have missed some calls, and without some other effort on your part you
will never know that.

The introduction of GRUU (RFC 5627) complicates things, because
temporary gruus expire when a binding expires. If you are using those
temporary bindings then it is important to know that.

Look at section 6.1 of RFC 5628 for some details on this.

Why are you asking these questions? Are you trying to figure out how to
implement a registrar? Or how to implement a UA that registers?


 Thanks,

 Paul

___
Sip-implementors mailing l

Re: [Sip-implementors] Difference Between SIP registration & reregistration

[Paul Kyzivat]

On 7/1/14 9:37 AM, Sourav Dhar Chaudhuri wrote:

Hi,
 How can be determined that whether SIP REGISTER is for new registration or 
reregistration by seeing the request.


You *can't* tell by examining the REGISTER.
And for the most part it doesn't matter.


   It seems that in case if the CSeq header value is considered then we can 
found something.  So please find my question


The sender of REGISTER is required to increment the CSeq for each 
REGISTER with the same Call-ID. The registrar is required to retain the 
call-id and cseq used to establish each binding. Look at bullet 6 of 
section 10.3 of 3261.



i) First Scenario
a) Consider an UE very first time sent REGISTER request with CSeq value as 
: 55 with one contact. Call-ID: 123 with expires 60
b)  It got successfully registered.
c) Now with 50  seconds  UE sends second REGISTER request with CSeq value 
as 40 with same contact . different Call ID 456 [Whether CSeq value has to be 
increased since call ID is different]

but still with this behavior whether Second Register will be entertained?


Above is valid. The binding is replaced.


ii) Second Scenario:
  a) UE very first time sent REGISTER request with CSeq value as : 55 with 
Expiry = 60 and Call-Id: 345 with one contact
  b)  It got successfully registered. This registration will be over after 
60 seconds

 c)  After 120 seconds


So binding has expired.

   UE sends second  REGISTER request with CSeq value as 70 and 
different Call-Id: 789 with same contact . How second REGISTER will be 
differentiated with new registration or reregistration.


This is valid as a new registration. So the binding was present, then 
absent, then present again.



iii) Second Scenario:


*Third*


  a) UE very first time sent REGISTER request with CSeq value as : 55 with 
Expiry = 60 and Call-Id: 876 with one contact
  b)  It got successfully registered.

 c) within 50 seconds UE sends second  REGISTER request with CSeq value as 
70 and different Call-Id: 321 with same contact with Expiry = 0 . Whether UE 
will be deregistered?


Yes. The new registration is valid, replacing the old one, and then 
immediately expiring.


In the normal case where you establish a registration and then attempt 
to maintain it by refreshing before it expires, it may be possible that 
your refresh will be "late". If it arrives on time then it is a refresh, 
and if it arrives late then it is a new registration.


And you can do that using the same call-id or different ones. You SHOULD 
do it using the same call-id. If you use the same call-id then you must 
use increasing cseq values. That helps to detect screw ups, because they 
will be rejected.


Of course, during the period when your registration was expired you may 
have missed some calls, and without some other effort on your part you 
will never know that.


The introduction of GRUU (RFC 5627) complicates things, because 
temporary gruus expire when a binding expires. If you are using those 
temporary bindings then it is important to know that.


Look at section 6.1 of RFC 5628 for some details on this.

Why are you asking these questions? Are you trying to figure out how to 
implement a registrar? Or how to implement a UA that registers?


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] FROM Header Query

[Paul Kyzivat]

On 6/27/14 1:14 PM, NK wrote:

Dear All,

We are getting the below FROM header from one of my client. Can you please
help me to get the answer on this, whether this is valid format?
From: "\241\271\324jE\032@d\200\252\bk\222\264" 
;tag=3612846472-761912


(I presume you are concerned with the display-name.)

It seems to be "valid", but the display name may not mean what was 
intended. It is actually equivalent to the string that has all the "\"s 
stripped:


"241271324jE032@d200252bk64"

(Each "\" just protects the following character from any *special* 
interpretation.)


I presume it is intending \nnn to mean something, but I don't know what.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Enconding of Callee Capabilities Priority feature-tag as string och numeric bnf-construct

[Paul Kyzivat]

Taisto,

You raise an interesting question.
I don't think it was one that was considered at the time.

The callerprefs/callee-caps work was under development for a long time 
before it finally became RFCs. Most of the definition of the semantics 
of individual capabilities was done quite early in that process, when 
the semantics of matching was very loosely defined.


It was toward the end of that process when RFC 2533 was incorporated as 
the say to do matching. When that was adopted, then the capability 
syntax for ranges was added. We probably should have revisited the 
definition of capabilities that have numeric values, such as priority. 
But I guess we didn't.


Bottom line: I don't think there is a complete answer to your question. 
You might want to file an erratum against RFC 3840.


There seem to be two choices:

- encode the value as a 'token-nobang' containing only digits.

- encode the value as a 'numeric'.

Note that the way the matching rules are defined in 3841 the two 
representations above are compatible. So for purposes of callerprefs 
matching you can use either form, or one form in the capability and the 
other form in the preference, and just accept the match that results.


That means, for callerprefs matching, an integer would only represent 
itself, not it and all larger values.


Understanding the meaning for purposes other than callerpref matching 
could still follow the semantic description - that for a single integer 
it means requests with priorities equal or greater will be handled.


Good luck,
Paul

On 6/11/14 6:00 AM, Taisto Qvist wrote:

Hey folks,

I've been looking into caller preferences and callee capabilities, and more specifically 
the "Priority" feature tag and how it should be encoded/interpreted.

The definition according to RFC3840 says:

Summary of the media feature indicated by this tag: The sip.priority
feature tag indicates the call priorities the device is willing to
handle. A value of X means that the device is willing to take
requests with priority X and higher. This does not imply that a
phone has to reject calls of lower priority. As always, the
decision on handling of such calls is a matter of local policy.

Values appropriate for use with this feature tag: An integer. Each
integral value corresponds to one of the possible values of the
Priority header field as specified in SIP [1].

At the same time, the BNF, indicates possible "data-types" as:

feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list
/ string-value ) RDQUOT]
enc-feature-tag = base-tags / other-tags
base-tags = "audio" / "automata" /
"class" / "duplex" / "data" /
"control" / "mobility" / "description" /
"events" / "priority" / "methods" /
"schemes" / "application" / "video" /
"language" / "type" / "isfocus" /
"actor" / "text" / "extensions"

tag-value-list = tag-value *("," tag-value)
tag-value = ["!"] (token-nobang / boolean / numeric)
token-nobang = 1*(alphanum / "-" / "." / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
boolean = "TRUE" / "FALSE"
numeric = "#" numeric-relation number
numeric-relation = ">=" / "<=" / "=" / (number ":")
number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]

The ambiguity I am trying to resolve, is that "values appropriate" says *integer*, which would at 
first glance tell me to use the "numeric" construct for tag-value. This would give me the possibility 
to use values such as ;priority="#<=10" or similar for describing intervals/ranges of priority.

But that collides with the summary description which says: "A value of X meanspriority X and 
higher"...which would make the ">=;<=;=" operators redundant.

At the same time, RFC3841 indicates that the matching process:

The matching
rules in RFC 2533 only require an implementation to know whether the
feature tag is a numeric, token, or quoted string (booleans can be
treated as tokens).

Where the presence of param="#" indicates numeric. Without the "#", 
;priority="10" becomes a token, and would be compared case-insensitive.

"Priority X and higher" indicates numeric analysis, wheras token comparison 
does not.

So, which is it?

How is everyone else interpreting this?

Regards
Taisto Qvist
IP-Solutions.se












___
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] Validation of Alert-Info header value

[Paul Kyzivat]

I agree with Brett. It is unclear exactly what you are asking.

Also, *why* are you asking? Do you want to use something peculiar? Or 
are you receiving something that is causing you grief?


Note that there are inherent problems with Alert-Info - if sent from 
caller to callee there can be trust issues in whether you want to 
attempt to dereference the URI. If you are actually interested in using 
Alert-Info then you might want to look at:


http://tools.ietf.org/html/draft-ietf-salud-alert-info-urns-12

It is almost done - soon to become an RFC.

Thanks,
Paul

On 6/6/14 11:58 AM, Brett Tate wrote:

Is the below value acceptable in the Alert-Info header value?

$@#$%^&*()_+{}:"<>?


The following is the ABNF.  I'm not sure what Alert-Info header position
applies to your question.

Alert-Info   =  "Alert-Info" HCOLON alert-param *(COMMA alert-param)
alert-param  =  LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
___
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] RTP start time in case of PRACK

[Paul Kyzivat]

On 5/19/14 11:26 AM, Rajesh wrote:

Thanks Paul. Sorry, i didn't get the point that "From the UAC's
perspective it can still start toward the UAC as soon as the INVITE is
sent.". May i know how UAC can start the RTP as it has not negotiated
media parameters with UAS and doesn't know the port. Please be informed
that we have SDP in INVITE.


The UAC can't start to *send* until it has received an answer. But it 
may start to *receive* RTP as soon as it has sent the offer. My point 
about the UAC *perspective* is that it doesn't know about what is 
happening on the wire or at the UAS, only what messages it has sent and 
received. So while in fact there is a time window after it sends the 
offer before there is a possibility of RTP being sent, it has no way of 
knowing how big that window is.


Thanks,
Paul


UAC -> UAS (Invite) includes SDP offer
UAS -> UAC (100 trying)
UAS -> UAC (180 Ringing Require 100rel header is set) includes SDP answer
UAC -> UAS (PRACK to 180 Ringing)
UAS -> UAC (200 OK to PRACK)
UAS -> UAC (200 OK to invite) No SDP
UAC -> UAS (ACK to 200 OK for invite)

Regards
Rajesh


On Mon, May 19, 2014 at 4:17 PM, Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote:

On 5/19/14 10:58 AM, Rajesh wrote:

Hi,

In the below call flow, when the UAC and UAS can start
transmitting RTP
packets. I think RTP session can be started after UAS receives
PRACK for
180 ringing. I would really appreciate your opinion on this. Thanks


The use of 180rel doesn't alter when RTP can start. From the UAC's
perspective it can still start toward the UAC as soon as the INVITE
is sent. From the UAS perspective it can't start toward the UAC
until the UAS has received the offer (the INVITE). There is no
reason why the UAS must wait for the prack. However the UAS might
*want* to wait for the prack before starting to send, since that
gives it more assurance that things are in good shape.

For instance, if something in the middle is gating the flow of RTP
in both directions until the answer is received, then waiting for
the prack will avoid early media being dropped.

 Thanks,
 Paul

UAC -> UAS (Invite)
UAS -> UAC (100 trying)
UAS -> UAC (180 Ringing Require 100rel header is set) includes
SDP Body
UAC -> UAS (PRACK to 180 Ringing)
UAS -> UAC (200 OK to PRACK)
UAS -> UAC (200 OK to invite) No SDP
UAC -> UAS (ACK to 200 OK for invite)


Regards
Rajesh
_
Sip-implementors mailing list
sip-implement...@lists.cs.__columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/__mailman/listinfo/sip-__implementors
<https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors>


_
Sip-implementors mailing list
sip-implement...@lists.cs.__columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/__mailman/listinfo/sip-__implementors
<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] RTP start time in case of PRACK

[Paul Kyzivat]

On 5/19/14 10:58 AM, Rajesh wrote:

Hi,

In the below call flow, when the UAC and UAS can start transmitting RTP
packets. I think RTP session can be started after UAS receives PRACK for
180 ringing. I would really appreciate your opinion on this. Thanks


The use of 180rel doesn't alter when RTP can start. From the UAC's 
perspective it can still start toward the UAC as soon as the INVITE is 
sent. From the UAS perspective it can't start toward the UAC until the 
UAS has received the offer (the INVITE). There is no reason why the UAS 
must wait for the prack. However the UAS might *want* to wait for the 
prack before starting to send, since that gives it more assurance that 
things are in good shape.


For instance, if something in the middle is gating the flow of RTP in 
both directions until the answer is received, then waiting for the prack 
will avoid early media being dropped.


Thanks,
Paul


UAC -> UAS (Invite)
UAS -> UAC (100 trying)
UAS -> UAC (180 Ringing Require 100rel header is set) includes SDP Body
UAC -> UAS (PRACK to 180 Ringing)
UAS -> UAC (200 OK to PRACK)
UAS -> UAC (200 OK to invite) No SDP
UAC -> UAS (ACK to 200 OK for invite)


Regards
Rajesh
___
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] Call Hold Resume issue , inactive answer after sendonly

[Paul Kyzivat]

On 5/12/14 10:16 AM, Brett Tate wrote:

Hi,

I assume that Paul intended to indicate RFC6337.


Thanks Brett. Yes, 6337.

Thanks,
Paul


-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sander Rambags
Sent: Monday, May 12, 2014 4:54 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Call Hold Resume issue , inactive
answer after sendonly



RFC6637 ??? I don't think that's the one you mean.

Rg Sander

___
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] Call Hold Resume issue , inactive answer after sendonly

[Paul Kyzivat]

On 5/9/14 3:37 AM, Sander Rambags wrote:

No media stream after putting call on an off hold.

  1.  Call connected between A and B.
  2.  A holds the call with a=sendonly.
  3.  B sends 200 ok with a=inactive
  (In many cases this would be a=recvonly, but in some cases / vendors it
is a=inactive)
  4.  A resumes the call with a=recvonly
  5.  B sends 200 ok with a=inactive
  So no media stream

  My question:
  A) Is the response in 3. according to RFC3264 ?


Yes, this is permitted.


  B) What must A sent when put call off hold ?


A should offer the state that it *wants* to be in. If it's user hasn't 
requested hold then it should typically offer sendrecv.



  C) Other remarks on this issue ?


I don't understand the logic behind B's behavior here. Apparently it 
only wants a 2-way conversation or nothing. But while it seems odd it 
isn't "wrong".


You should look at RFC6637, especially section 5. It covers this general 
subject.


Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] A question about the automaton feature tag

[Paul Kyzivat]

On 4/29/14 8:50 PM, SIP Learner wrote:

So the 'automaton' used in examples in RFC 5359 and RFC 7088 should be
'automata', right?


Yes.


I had thought that 'automaton' might be specified in
some other RFC that I failed to locate.


When in doubt you can check the IANA registry:
https://www.iana.org/assignments/media-feature-tags/media-feature-tags.xhtml


Thanks!


-- Original ----------
*From: * "Paul Kyzivat";;
*Date: * Wed, Apr 30, 2014 00:20 AM
*To: * "ankur bansal"; "SIP
Learner";
*Cc: * "sip-implementors";
*Subject: * Re: [Sip-implementors] A question about the automaton
feature tag

On 4/29/14 10:42 AM, ankur bansal wrote:
 > sip.automata and automata represents same thing  i guess

That is arguable. The situation is somewhat complex.

At the time RFC3840 was being written somebody saw a similarity between
the tags being defined for it and feature tags that had been previously
defined for unrelated purposes. And also that the definition of feature
tags had defined matching rules. So it was decided to reuse the existing
definitions and mechanisms for feature tags. (In retrospect I think this
was an error, but nevertheless that is what was done.)

The callerprefs mechanism (RFC3841) that operates in proxies is generic
- it operates the same for all feature tags, and it is important that
proxies be able to do it even for features unknown to them. As a result,
it must be possible for a proxy to distinguish header field parameters
that are feature tags (caller prefs or callee capabilities), from
parameters that serve some other purpose. For that reason the "+" prefix
was introduced to identify parameters that are being used as feature tags.

BUT, drafts of callerprefs had been in progress for years, and there was
a desire to preserve some backward compatibility for those who had
implemented to those drafts. (In retrospect this was probably also a
mistake.) So the set of sip feature tags that had been in the draft were
designated "base tags". These are *special*, and are grandfathered. They
are to be used without the leading "+sip." even though they are defined
in the "sip tree" of feature tags. The text also *allows* the base tags
to be used with a "+sip." or even "sip." prefix.

Any other feature tags that are used MUST use the "+" prefix and the
full name of the tag including the prefix for the tree it falls within.

 > Either its set as sip.automata=true/false OR automata(true by default)

The following would all be ok:

automata
automata=true
automata=false
+sip.automata
+sip.automata=true
+sip.automata=false
sip.automata
sip.automata=true
sip.automata=false

Thanks,
Paul

 > Feature parameter(not feature tag) can be added to Contact header  by
 > UA(mostly some answering machine/voicemail server/IVR/announcement
 > server ) with value true or false
 >  True : Call handled by answering
 > machine/voicemail server/IVR/announcement server
 >   False : Call handled by human.
 > Mostly its seen when some server sends INVITE and add in Contact header .
 > Also this can be used in Register Contact header like sip.automata=false
 > to refuse to communicate with automation server .
 >
 > Thanks & regards
 > Ankur Bansal
 >
 >
 >
 >
 > On Tue, Apr 29, 2014 at 8:05 PM, SIP Learner  <mailto:rfc3...@foxmail.com>> wrote:
 >
 > Thanks Paul!
 >
 >
 > At first I thought automaton as a typo too, but I found out that the
 > most recent RFC7088 also use automaton instead of automata, that's
 > why I asked the question.
 >
 >
 >
 >
 >
 >
 >
 >
 > -- Original --
 > From:  "Paul Kyzivat"; <mailto:pkyzi...@alum.mit.edu>>;
 > Date:  Tue, Apr 29, 2014 08:35 PM
 > To:  "sip-implementors" <mailto:sip-implementors@lists.cs.columbia.edu>>;
 >
 > Subject:  Re: [Sip-implementors] A question about the automaton
 > feature tag
 >
 >
 >
 > I presume "automaton" is simply an error - a misspelling.
 > You can look in the iana registry for all the defined feature tags.
 >
 > On 4/29/14 3:27 AM, SIP Learner wrote:
 >  > Hi, guys!
 >  >
 >  >
 >  > I am reading RFC5359 for SIP services examples, some of the
 > message examples contain a Contact header parameter like the
following:
 >  >
 >  >
 >  > Contact:  <mailto:sips%3amu...@server.example.com>>;automaton
 >  > ;+sip.byeless;+sip.rendering="no"
 >  >
 >  >
 >  >
 >  > FRC5359 states that the automaton feature tag is d

Re: [Sip-implementors] A question about the automaton feature tag

[Paul Kyzivat]

On 4/29/14 10:42 AM, ankur bansal wrote:

sip.automata and automata represents same thing  i guess


That is arguable. The situation is somewhat complex.

At the time RFC3840 was being written somebody saw a similarity between 
the tags being defined for it and feature tags that had been previously 
defined for unrelated purposes. And also that the definition of feature 
tags had defined matching rules. So it was decided to reuse the existing 
definitions and mechanisms for feature tags. (In retrospect I think this 
was an error, but nevertheless that is what was done.)


The callerprefs mechanism (RFC3841) that operates in proxies is generic 
- it operates the same for all feature tags, and it is important that 
proxies be able to do it even for features unknown to them. As a result, 
it must be possible for a proxy to distinguish header field parameters 
that are feature tags (caller prefs or callee capabilities), from 
parameters that serve some other purpose. For that reason the "+" prefix 
was introduced to identify parameters that are being used as feature tags.


BUT, drafts of callerprefs had been in progress for years, and there was 
a desire to preserve some backward compatibility for those who had 
implemented to those drafts. (In retrospect this was probably also a 
mistake.) So the set of sip feature tags that had been in the draft were 
designated "base tags". These are *special*, and are grandfathered. They 
are to be used without the leading "+sip." even though they are defined 
in the "sip tree" of feature tags. The text also *allows* the base tags 
to be used with a "+sip." or even "sip." prefix.


Any other feature tags that are used MUST use the "+" prefix and the 
full name of the tag including the prefix for the tree it falls within.



Either its set as sip.automata=true/false OR automata(true by default)


The following would all be ok:

automata
automata=true
automata=false
+sip.automata
+sip.automata=true
+sip.automata=false
sip.automata
sip.automata=true
sip.automata=false

Thanks,
Paul


Feature parameter(not feature tag) can be added to Contact header  by
UA(mostly some answering machine/voicemail server/IVR/announcement
server ) with value true or false
 True : Call handled by answering
machine/voicemail server/IVR/announcement server
  False : Call handled by human.
Mostly its seen when some server sends INVITE and add in Contact header .
Also this can be used in Register Contact header like sip.automata=false
to refuse to communicate with automation server .

Thanks & regards
Ankur Bansal




On Tue, Apr 29, 2014 at 8:05 PM, SIP Learner mailto:rfc3...@foxmail.com>> wrote:

Thanks Paul!


At first I thought automaton as a typo too, but I found out that the
most recent RFC7088 also use automaton instead of automata, that's
why I asked the question.








-- Original --
From:  "Paul Kyzivat";mailto:pkyzi...@alum.mit.edu>>;
Date:  Tue, Apr 29, 2014 08:35 PM
To:  "sip-implementors"mailto:sip-implementors@lists.cs.columbia.edu>>;

Subject:  Re: [Sip-implementors] A question about the automaton
feature tag



I presume "automaton" is simply an error - a misspelling.
You can look in the iana registry for all the defined feature tags.

On 4/29/14 3:27 AM, SIP Learner wrote:
 > Hi, guys!
 >
 >
 > I am reading RFC5359 for SIP services examples, some of the
message examples contain a Contact header parameter like the following:
 >
 >
 > Contact: mailto:sips%3amu...@server.example.com>>;automaton
 > ;+sip.byeless;+sip.rendering="no"
 >
 >
 >
 > FRC5359 states that the automaton feature tag is defined in
RFC3840, but RFC3840 actually defined sip.automata instead of automaon.
 >
 >
 > What is the difference between automaton and sip.automata anyway?
Are they equivalent or are they different?
 >
 >
 > Thanks a lot!
 > ___
 > Sip-implementors mailing list
 > Sip-implementors@lists.cs.columbia.edu
<mailto: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
<mailto: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
<mailto: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] TCP/NAT handling in SIP

[Paul Kyzivat]

On 4/29/14 7:55 AM, VARUN BHATIA wrote:

Thanks Brett, is there any specific standard which indicates that INVITE
dialog will be using same connection of REGISTER ?


RFC 5626 is the only one


Thanks,
Varun


On Tue, Apr 29, 2014 at 4:35 PM, Brett Tate  wrote:


RFC 5626 will likely be helpful.


-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of VARUN BHATIA
Sent: Tuesday, April 29, 2014 6:52 AM
To: sip-implementors
Subject: [Sip-implementors] TCP/NAT handling in SIP

Hi,

If the UA is behind NAT registers on TCP and after that it initiates a
call
on same connection (may be another connection ?) after some time
connection
break now as soon as UA detect that the connection is closed it
initiates a
new REGISTER using new connection (It is not changing contact as it is
listening on default port).

1. Should UA send a re-invite/update for modifying the connection
status
within a call ?
2. If No, then whether it is recommended in any of standard that we
should
use the same connection for sending any request ?
3. Is there any RFC which mention the connection handling between
REGISTER
request and INVITE request ?

Any inputs are appreciated.

--
Regards,
Varun Bhatia
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


--

This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.







___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] A question about the automaton feature tag

[Paul Kyzivat]

I presume "automaton" is simply an error - a misspelling.
You can look in the iana registry for all the defined feature tags.

On 4/29/14 3:27 AM, SIP Learner wrote:

Hi, guys!


I am reading RFC5359 for SIP services examples, some of the message examples 
contain a Contact header parameter like the following:


Contact: ;automaton
;+sip.byeless;+sip.rendering="no"



FRC5359 states that the automaton feature tag is defined in RFC3840, but 
RFC3840 actually defined sip.automata instead of automaon.


What is the difference between automaton and sip.automata anyway? Are they 
equivalent or are they different?


Thanks a lot!
___
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] SDP offer answer model

[Paul Kyzivat]

On 4/17/14 1:02 PM, isshed wrote:

I want to make it inter-operable with Polycom's real presence desktop.


Then, an unsatisfying as it is, it may be best to first find out what 
Polycom supports in this regard.


From a standards perspective, SDP capability negotiation (RFC 5939 and 
friends) were designed to situations like this. But this isn't widely 
deployed.


Thanks,
Paul


On Thu, Apr 17, 2014 at 6:43 PM, Paul Kyzivat  wrote:

On 4/17/14 12:45 AM, isshed wrote:


Thanks Paul and everyone ...

I am designing Phone1 to use only one audio and one video. Phone1
supports secured media as well. so it is offering both secure/non
secure to phone2 and expects phone2 to select among the given m-lines
(RTP and SRTP).



And what is this expected to work with?
That is probably more important than what is theoretically correct.

 Thanks,
 Paul



Thanks.

On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyzivat 
wrote:


I read a number of the replies to this, but couldn't find an obvious
place
to jump in, so I'm just replying here.

An offer multiple audio and/or video m-lines does not mean that they are
*alternatives*. Absent some explicit indication, there is no way to know
what the offerer's intent is in offering them, nor does the offerer know
what the answerer's intent is in accepting them.

In the given example, if the offerer only intends to use one audio and
one
video, then it can arbitrarily choose one, and hope that this works
reasonably for the answerer. In that case it should do another O/A and
reject the ones it doesn't intend to use.

If you are designing phone1, and your goal is to have one audio and one
video, but you want to offer more possibilities than you can express with
one audio and one video m-line, then post back with what you are trying
to
accomplish, and we can discuss recommended ways of achieving that.

  Thanks,
  Paul


On 4/16/14 2:51 AM, isshed wrote:



Hi All,

I have 1 basic query regarding ofer-answer model


Phone1 is sending the offer with 2 audio mlines and 2 video mline like
as follows.


m=audio 3342 RTP/SAVP 0 8 127
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:22
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=audio 3342 RTP/AVP 0 8 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=video 5544 RTP/SAVP 109
a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:33
a=rtpmap:109 H264/9
a=fmtp:109 profile-level-id=42800d
m=video 5544 RTP/AVP 109
a=rtpmap:109 H264/9
a=fmtp:109 profile-level-id=42800d

and phone 2 is responding with all the 4 m lines as follows

 m=audio 4344 RTP/SAVP 0 8 127
 a=rtpmap:0 PCMU/8000
 a=rtpmap:8 PCMA/8000
 a=rtpmap:127 telephone-event/8000
 m=audio 4344 RTP/AVP 0 8 119
 a=sendrecv
 a=rtpmap:0 PCMU/8000
 a=rtpmap:8 PCMA/8000
 a=rtpmap:119 telephone-event/8000
 a=fmtp:119 0-15
 m=video 7878 RTP/SAVP 109
 a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:44
 a=rtpmap:109 H264/9
 a=fmtp:109 profile-level-id=42800d
 m=video 7878 RTP/AVP 109
 a=sendrecv
 a=rtpmap:109 H264/9
 a=fmtp:109 profile-level-id=42801e; max-mbps=49000;
max-br=20010;
sar=13




Which m line should phone1 select to send and receive audio and video.

let me know is query is not clear.


Thanks,
___
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









___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SDP offer answer model

[Paul Kyzivat]

On 4/17/14 12:45 AM, isshed wrote:

Thanks Paul and everyone ...

I am designing Phone1 to use only one audio and one video. Phone1
supports secured media as well. so it is offering both secure/non
secure to phone2 and expects phone2 to select among the given m-lines
(RTP and SRTP).


And what is this expected to work with?
That is probably more important than what is theoretically correct.

Thanks,
Paul


Thanks.

On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyzivat  wrote:

I read a number of the replies to this, but couldn't find an obvious place
to jump in, so I'm just replying here.

An offer multiple audio and/or video m-lines does not mean that they are
*alternatives*. Absent some explicit indication, there is no way to know
what the offerer's intent is in offering them, nor does the offerer know
what the answerer's intent is in accepting them.

In the given example, if the offerer only intends to use one audio and one
video, then it can arbitrarily choose one, and hope that this works
reasonably for the answerer. In that case it should do another O/A and
reject the ones it doesn't intend to use.

If you are designing phone1, and your goal is to have one audio and one
video, but you want to offer more possibilities than you can express with
one audio and one video m-line, then post back with what you are trying to
accomplish, and we can discuss recommended ways of achieving that.

 Thanks,
 Paul


On 4/16/14 2:51 AM, isshed wrote:


Hi All,

I have 1 basic query regarding ofer-answer model


Phone1 is sending the offer with 2 audio mlines and 2 video mline like
as follows.


m=audio 3342 RTP/SAVP 0 8 127
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:22
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=audio 3342 RTP/AVP 0 8 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=video 5544 RTP/SAVP 109
a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:33
a=rtpmap:109 H264/9
a=fmtp:109 profile-level-id=42800d
m=video 5544 RTP/AVP 109
a=rtpmap:109 H264/9
a=fmtp:109 profile-level-id=42800d

and phone 2 is responding with all the 4 m lines as follows

m=audio 4344 RTP/SAVP 0 8 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=audio 4344 RTP/AVP 0 8 119
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:119 telephone-event/8000
a=fmtp:119 0-15
m=video 7878 RTP/SAVP 109
a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:44
a=rtpmap:109 H264/9
a=fmtp:109 profile-level-id=42800d
m=video 7878 RTP/AVP 109
a=sendrecv
a=rtpmap:109 H264/9
a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010;
sar=13




Which m line should phone1 select to send and receive audio and video.

let me know is query is not clear.


Thanks,
___
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




___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] SDP offer answer model

[Paul Kyzivat]

I read a number of the replies to this, but couldn't find an obvious 
place to jump in, so I'm just replying here.


An offer multiple audio and/or video m-lines does not mean that they are 
*alternatives*. Absent some explicit indication, there is no way to know 
what the offerer's intent is in offering them, nor does the offerer know 
what the answerer's intent is in accepting them.


In the given example, if the offerer only intends to use one audio and 
one video, then it can arbitrarily choose one, and hope that this works 
reasonably for the answerer. In that case it should do another O/A and 
reject the ones it doesn't intend to use.


If you are designing phone1, and your goal is to have one audio and one 
video, but you want to offer more possibilities than you can express 
with one audio and one video m-line, then post back with what you are 
trying to accomplish, and we can discuss recommended ways of achieving that.


Thanks,
Paul

On 4/16/14 2:51 AM, isshed wrote:

Hi All,

I have 1 basic query regarding ofer-answer model


Phone1 is sending the offer with 2 audio mlines and 2 video mline like
as follows.


m=audio 3342 RTP/SAVP 0 8 127
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:22
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=audio 3342 RTP/AVP 0 8 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=video 5544 RTP/SAVP 109
a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:33
a=rtpmap:109 H264/9
a=fmtp:109 profile-level-id=42800d
m=video 5544 RTP/AVP 109
a=rtpmap:109 H264/9
a=fmtp:109 profile-level-id=42800d

and phone 2 is responding with all the 4 m lines as follows

   m=audio 4344 RTP/SAVP 0 8 127
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:127 telephone-event/8000
   m=audio 4344 RTP/AVP 0 8 119
   a=sendrecv
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:119 telephone-event/8000
   a=fmtp:119 0-15
   m=video 7878 RTP/SAVP 109
   a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:44
   a=rtpmap:109 H264/9
   a=fmtp:109 profile-level-id=42800d
   m=video 7878 RTP/AVP 109
   a=sendrecv
   a=rtpmap:109 H264/9
   a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010; sar=13




Which m line should phone1 select to send and receive audio and video.

let me know is query is not clear.


Thanks,
___
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] Query on Contact header parameter

[Paul Kyzivat]

You have now received answers to the question you asked.
But not to the one you should have asked: how can you do this in a way 
that doesn't violate standards?


The procedure for managing new header field parameters was updated by 
RFC 3968. There is an IANA registry, and you need an RFC to define a new 
one. I assume you haven't published an RFC to define your proprietary 
parameter.


An alternative that is open to you is a feature tag, as defined in RFC 
3840. In particular you can use feature tags from the "URI tree" to 
express vendor-specific features.


UAs are expected to ignore parameters they don't understand, so you can 
"get away" with using an illegal unregistered parameter, but you may run 
into trouble if the name you choose is later chosen as the name of some 
standard option. Or if you do interop testing, someone may identify you 
as non-complying for using a non-standard option.


Thanks,
Paul

On 3/21/14 6:33 AM, J C Sunil Kumar Reddy wrote:

Hi All,

I need to send a proprietary parameter in contact header in an INVITE
message to other end.
Something like this:

Contact: "Sunil" ;category:strvalue

Here "category:strvalue" is my proprietary parameter. Where "category" is a
param name and "strvalue" is the value.

What does the SIP standard specify? whether it should be colon(:) or
Equals(=)?
I mean according to SIP standards, which is the correct one?

category:strvalue
or
category=strvalue
or something else?

Regards,
Sunil
___
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] Fwd: BYE request processing in a statefull proxy.

[Paul Kyzivat]

Assuming P1 and P2 are truly proxies, and not B2BUAs, then (1) is 
correct and (2) is not. What do you find in 3261 that makes you think it 
allows (2).

Thanks,
Paul

On 3/1/14 12:10 AM, Kiran Kumar wrote:
> Dear All,
>
> I have a confusion in the following scenario.
> After establishing a connection between two peers in a SIP trapezoid which
> of the following sequence is correct while processing BYE where P1 and P2
> are statefull proxies.
>
> 1. UACP1  P2UAS
>
>  BYE -> BYE -> BYE -> BYE
>  200  <-  200  <- 200   <-  200
>
> or
>
> 2. UACP1  P2UAS
>
>  BYE -> BYE
>  200  <- 200
>
>  BYE-> BYE
>  200  <- 200
>
>   BYE -> BYE
>   200  <- 200
>
> RFC 3665 is showing scenario 1. but RFC 3261 does not explain anything
> about proxy processing of non-invite request but indirectly says 2 is also
> correct while explaining transaction in section 17.
>
> Thanks,
> Kiran.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SIP REFER to a Blind Call Transfer

[Paul Kyzivat]

On 2/26/14 12:03 PM, Brett Tate wrote:
> Hi Paul,
>
> Yes; I likely misinterpreted the meaning of "NOTIFY (200 OK)" within the
> question.
>
> I also agree that some devices behave as you and Parveen mentioned.  I'm
> not aware of the behavior explicitly documented within an RFC.  RFC 5359
> does document it that way for attended transfer; however it doesn't
> document a transfer failure recovery.

For blind transfer it does present some UI challenges. The transferring 
party has presumably hung up the phone. So do you alert to get them back 
if the transfer fails?

It is probably easier to handle with a soft phone, that has more UI options.

But this is clearly more user friendly that silently letting the 
transfer fail.

Thanks,
Paul

> Thanks,
> Brett
>
>> -Original Message-
>> From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
>> Sent: Wednesday, February 26, 2014 11:05 AM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] SIP REFER to a Blind Call Transfer
>>
>> Brett,
>>
>> The facts of Parveen's case arent entirely clear here.
>> You both might be correct.
>>
>> I *think* Parveen is saying that the UAC is waiting for a NOTIFY
>> containing a sipfrag with the 200 OK for the referred invite.
>> Presumably
>> it could have received an earlier notify reporting a provisional
>> response.
>>
>> AFAIK it is fine for the UAC to keep its own invite dialog active until
>> it gets a notification that the referred INVITE has completed
>> successfully, or until the subscription terminates. As Parveen notes,
>> this allows the UAC to recover the dialog if the refer is unsuccessful.
>>
>>  Thanks,
>>  Paul
>>
>>
>>
>> On 2/26/14 6:48 AM, Brett Tate wrote:
>>> Hi,
>>>
>>> RFC 6665 and RFC 3515 indicate that a NOTIFY must immediately be
>> sent.
>>> RFC 6665 also introduced Timer N which can impacts things if the
>> NOTIFY is
>>> delayed until transfer-to device answers.
>>>
>>> RFC 6665 section 4.2.1.2:
>>>
>>> "Upon successfully accepting or refreshing a subscription, notifiers
>>>MUST send a NOTIFY request immediately to communicate the current
>>>resource state to the subscriber."
>>>
>>> RFC 3515 section 2.4.2:
>>>
>>> "If a REFER request is accepted (that is, a 2xx class response is
>>>returned), the recipient MUST create a subscription and send
>>>notifications of the status of the refer as described in Section
>>>2.4.4."
>>>
>>> RFC 6665 section 4.1.2.4:
>>>
>>> "The subscriber can expect to receive a NOTIFY request from each node
>>>which has processed a successful subscription or subscription
>>>refresh.  To ensure that subscribers do not wait indefinitely for a
>>>subscription to be established, a subscriber starts a Timer N, set
>> to
>>>64*T1, when it sends a SUBSCRIBE request.  If this Timer N expires
>>>prior to the receipt of a NOTIFY request, the subscriber considers
>>>the subscription failed, and cleans up any state associated with
>> the
>>>subscription attempt."
>>>
>>>
>>>> -Original Message-
>>>> From: Parveen Verma [mailto:parveen.s...@gmail.com]
>>>> Sent: Wednesday, February 26, 2014 2:41 AM
>>>> To: sip-implementors
>>>> Subject: Re: [Sip-implementors] SIP REFER to a Blind Call Transfer
>>>>
>>>> Hello,
>>>>
>>>> The UAC after sending the REFER does not disconnect the call (sends
>>>> BYE) until it receives the NOTIFY (200 OK). The other way can also
>> be
>>>> that AS sends BYE to A's UAC just after sending NOTIFY (200 OK).
>>>>
>>>> In our AS does not sends NOTIFY (200 OK) until it receives the
>> answer
>>>> from C so that there is a option left to A to unhold the call with
>> B.
>>>> But still I am not finding any reference of any Standard which says
>>>> so.
>>>>
>>>> So I am looking for some reference for this behaviour or what kind
>> of
>>>> behaviour other AS does in Blind Call Transfer case.
>>>>
>>>> --
>>>> Thanks & Regards
>>>> Parveen Verma
>>>> ___
>>>> Sip-implementors mailing list
>>>> Sip-implementors@lists.cs.columbia.edu
>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SIP REFER to a Blind Call Transfer

[Paul Kyzivat]

Brett,

The facts of Parveen's case arent entirely clear here.
You both might be correct.

I *think* Parveen is saying that the UAC is waiting for a NOTIFY 
containing a sipfrag with the 200 OK for the referred invite. Presumably 
it could have received an earlier notify reporting a provisional response.

AFAIK it is fine for the UAC to keep its own invite dialog active until 
it gets a notification that the referred INVITE has completed 
successfully, or until the subscription terminates. As Parveen notes, 
this allows the UAC to recover the dialog if the refer is unsuccessful.

Thanks,
Paul



On 2/26/14 6:48 AM, Brett Tate wrote:
> Hi,
>
> RFC 6665 and RFC 3515 indicate that a NOTIFY must immediately be sent.
> RFC 6665 also introduced Timer N which can impacts things if the NOTIFY is
> delayed until transfer-to device answers.
>
> RFC 6665 section 4.2.1.2:
>
> "Upon successfully accepting or refreshing a subscription, notifiers
>   MUST send a NOTIFY request immediately to communicate the current
>   resource state to the subscriber."
>
> RFC 3515 section 2.4.2:
>
> "If a REFER request is accepted (that is, a 2xx class response is
>   returned), the recipient MUST create a subscription and send
>   notifications of the status of the refer as described in Section
>   2.4.4."
>
> RFC 6665 section 4.1.2.4:
>
> "The subscriber can expect to receive a NOTIFY request from each node
>   which has processed a successful subscription or subscription
>   refresh.  To ensure that subscribers do not wait indefinitely for a
>   subscription to be established, a subscriber starts a Timer N, set to
>   64*T1, when it sends a SUBSCRIBE request.  If this Timer N expires
>   prior to the receipt of a NOTIFY request, the subscriber considers
>   the subscription failed, and cleans up any state associated with the
>   subscription attempt."
>
>
>> -Original Message-
>> From: Parveen Verma [mailto:parveen.s...@gmail.com]
>> Sent: Wednesday, February 26, 2014 2:41 AM
>> To: sip-implementors
>> Subject: Re: [Sip-implementors] SIP REFER to a Blind Call Transfer
>>
>> Hello,
>>
>> The UAC after sending the REFER does not disconnect the call (sends
>> BYE) until it receives the NOTIFY (200 OK). The other way can also be
>> that AS sends BYE to A's UAC just after sending NOTIFY (200 OK).
>>
>> In our AS does not sends NOTIFY (200 OK) until it receives the answer
>> from C so that there is a option left to A to unhold the call with B.
>> But still I am not finding any reference of any Standard which says
>> so.
>>
>> So I am looking for some reference for this behaviour or what kind of
>> behaviour other AS does in Blind Call Transfer case.
>>
>> --
>> Thanks & Regards
>> Parveen Verma
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] feature-tags in Contact of invite

[Paul Kyzivat]

On 2/23/14 8:32 PM, Aditya Kumar wrote:
> Hi,
> What is the use of UE keeping feature-tags in Contact Header of INVITE?

They indicate the features of the UAC at the time of the INVITE.

One commonly used here is isFocus.

> I see some UEs keeping. feature-tags in contact of REGISTER make sense...not 
> sure about having it in INVITE?
> also if UE wants why not it use "Feature-Caps "Header? I see as per rfc only 
> servers use this?

Feature-Caps is explicitly intended for use when feature tags *cannot* 
be used.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] B updates before 200OK(INV) should it include session timer?

[Paul Kyzivat]

On 2/21/14 6:38 AM, Brett Tate wrote:
>> All is well but what happens with the Session Timer response?
>
> RFC 4028 basically allows the Session-Timer to be negotiated with every
> INVITE/UPDATE request.  The last 2xx response wins.
>
> If UPDATE 2xx sent/received within an INVITE, refreshing/expiring would be
> done based upon the UPDATE 2xx's added/missing Session-Expires.  When the
> subsequent INVITE 2xx is sent/received, refreshing/expiring would be done
> based upon the INVITE 2xx's added/missing Session-Expires.  If I recall
> correctly, the RFC provides some guidance to reduce the impacts of
> potential race conditions.

I generally agree with Brett.

I think this is a bit fuzzy in the rfc when the UPDATE occurs before the 
initial invite transaction completes.

To be safe, I would recommend that B-side do put SE in the UPDATE, and 
then make sure that what is in the 200 (INV) is consistent with all that 
went before, so that both sides will agree on the expiration time and 
refresher regardless of whether taking the result from the UPDATE or the 
INVITE.

IMO it is not safe to omit SE from the UPDATE - that might result in no 
session timer.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] [dispatch] SIP INVITE server transaction

[Paul Kyzivat]

sunil,

This is the wrong mailing list for such a query.
You should try Sip-implementors@lists.cs.columbia.edu

Good luck,
Paul

On 2/13/14 8:36 AM, sunil kumar sinha wrote:
> Hi,
>
> SIP INVITE client transaction can retransmit INVITE seven times in case
> of unreliable transport before it gets timeout.
>
> My queries as below
> 1.)Does SIP INVITE server transaction also retransmit INVITE?
> 2.)If yes, then please share some detail on it.
>
> Thanks & Regard
> sunil
>
>
>
> 
>
> Get your own *FREE* website, *FREE* domain & *FREE* mobile app with
> Company email.
>   *Know More >*
> 
>
>
>
> ___
> dispatch mailing list
> dispa...@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Sending proprietary information in SIP INVITE

[Paul Kyzivat]

Adelia,

The problem is that carriers and other intermediaries have decided that 
they are free to change anything they want in sip signaling, regardless 
of SIP spec rules that they not do so. So you will have to take it up 
with them.

It appears to me that the general attitude is: we will allow what we 
must to make the specific features we care about work - breaking any 
usage we don't explicitly embrace is a feature rather than a bug.

Thanks,
Paul

On 1/29/14 4:48 PM, Adelia Chetreanu wrote:
> I need to send a 10 digit unique ID over the network.
> I've been doing it for years by replacing the INVITE FROM header with the 10 
> digit value.
> Looks like a phone number.
>
> Lately, I'm facing an on/off problem, the ANI gets replaced with Anonymous 
> every 70-80 calls or so. Randomly, no pattern.
> I believe it to be related to a particular carrier we traverse and I have no 
> control over it.
> It breaks one of our major features.
>
> This is an example:
>
> Sending:
> INVITE sip:1415xxxyyy@10.10.10.10:5060 SIP/2.0
> Via: SIP/2.0/UDP 
> 10.10.10.2:5060;received=10.10.10.2;branch=z9hG4bK-d87543-603a7a3e7269fb4d-1--d87543-;rport=5060
> Max-Forwards: 69
> Contact: 
> To: 
> From: ;tag=2b5d3157
> Call-ID: MzQ3NzFjNGQ1NjY1MDBmNjMxMDAyOTA0NWVhNjVmNzc.
> CSeq: 1 INVITE
> Content-Type: application/sdp
> Content-Length: 186
>
> Receiving:
>
>
>
>
> Request URI: sip:+1415xxx@66.66.66.66:5060
> From: "Anonymous" ;tag=gK0a240fff
> To: 
> Call-ID: 
> 218763914_18988818@8.13.234.114
> CSeq: 20798 INVITE
> Contact: "Anonymous" 
> P-Asserted-Identity: 
>
>
> We extract 4153436545 instead of 5180943774 on the called party side, and our 
> feature bombs.
>
> While I follow up with our carrier, what other options do I have?
> What could I use (header or parameter) to send my private info transparently 
> through the network?
> Must be in INVITE.
>
> I have found post "Private Header" from 2009, that suggests:
> - private header, add your own
> - MIME data
> - userinfo parameter in Request URI
>
> Each one has its challenges for my app - do I have other options?
> Thank you!
> A.C.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SIP:- difference between route and via

[Paul Kyzivat]

On 1/20/14 9:15 AM, Iñaki Baz Castillo wrote:
> 2013/10/28 vipin juneja :
>> Hi Guys...
>>
>> can anybody explain me the difference between Via, route, recordroute ,
>
> http://tools.ietf.org/html/rfc3261

Yes, you should always start there.

In brief:

- Via is used for routing the response to a request
- Route is used for specifying the path a request should follow
- Record-Route is used to determine the Route that should be used
   by subsequent requests in a dialog.

Happy Reading,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Require: 100rel header in re-INVITE

[Paul Kyzivat]

Adding to what Brett says...

An issue with 3261 is that there is no precise definition of the 
duration over which a "Supported:xyz" is applicable. It might be for the 
lifetime of the device sending it, it might be for the duration of the 
dialog in which it is sent, or it might only be for the duration of the 
transaction in which it is sent.

So worst case, it might change from transaction to transaction. When 
assuming it applies for longer, you are wise to be prepared for your 
assumption to be wrong.

If the device sending the 420 is just an "ordinary device", and nothing 
is really changed since the prior invite, then IMO it is acting 
perversely, but is not technically violating anything.

Thanks,
Paul

On 1/17/14 7:11 AM, Brett Tate wrote:
>> Is it OK to include Require header with 100rel
>> in the re-INVITE, UA1 has already showed that
>> it supports this extension.
>
> Yes; however you might receive a 420.
>
>
>> Why should UA1 reject this message with 420 response.
>
> Among other potential reasons, a B2BUA is involved and re-INVITE reached a 
> different UAS which doesn't support 100rel.
>
> And for completeness since you are attempting to use 100rel for re-INVITE, be 
> aware that RFC 6141 updates RFC 3261.
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Even Port number for RTP in SDP

[Paul Kyzivat]

NK,

By default RTP goes on an even port and RTCP goes on the following odd 
port. IIRC (I'm not looking this up) if the declared port is odd you are 
still supposed to round it down to the previous even one for the RTP and 
use the odd one for the RTCP.

But then look at RFC 3605. It defines a=rtcp:. With that, you can 
put the RTCP on a port independent of where the RTP goes. In that case 
the odd port in the m-line should be honored for the RTP.

Unfortunately, in general if you use a=rtcp in an offer you have no 
guarantee that the answerer will support this extension.

Thanks,
Paul

On 1/10/14 11:07 AM, NK wrote:
> Dear All,
>
> Can you please help me on one issue, where one of client is complaining
> that they need RTP even port in SDP not the ODD.  Which is Fax Call.
>
> Although I checked the RFC 2327 & 4566 for SDP. In RFC 2327 its clearly
> mentioned that we should use even port for RTP compliance, whereas in RFC
> 4566 Its not clearing that is it MANDATORY or not.
>
> Can you please help me on this.
>
>>From RFC2327
>
>
>
> m=   
>
>
>
> A session description may contain a number of media descriptions.   Each
> media description starts with an "m=" field, and is terminated by either
> the next "m=" field or by the end of the session description.A media field
> also has several sub-fields:
>
> o The first sub-field is the media type.  Currently defined media
> are "audio",
> "video", "application", "data" and "control", though this list may be
> extended as new communication modalities emerge (e.g.,telepresense).The
> difference between "application" and "data" is that the former is a media
> flow such as whiteboard information, and
>
> the latter is bulk-data transfer such as multicasting of program executables
> which will not typically be displayed to the user. "control" is used to
> specify an additional conference control channel for the session.
>
> o The second sub-field is the transport port to which the media stream
> will be sent.  The meaning of the transport port depends on the network
> being used as specified in the relevant "c" field and on the transport
> protocol defined in the third sub-field.  Other ports used by the media
> application (such as the RTCP port, see
>
>   [2]) should be derived algorithmically from the base media port.
>
>
> *Note: For transports based on UDP, the value should be in the range 1024
> to 65535 inclusive.  For RTP compliance it should be an even number.*
>
>
> *Regards,*
>
> *Nitin Kapoor*
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] offer answer model

[Paul Kyzivat]

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 SDP MUST have a matching media stream for each media stream in
the previous SDP.  In other words, if the previous SDP had N "m="
lines, the new SDP MUST have at least N "m=" lines.  The i-th media
stream in the previous SDP, counting from the top, matches the i-th
media stream in the new SDP, counting from the top.  This matching is
necessary in order for the answerer to determine which stream in the
new SDP corresponds to a stream in the previous SDP.  Because of
these requirements, the number of "m=" lines in a stream never
decreases, but either stays the same or increases.  Deleted media
streams from a previous SDP MUST NOT be removed in a new SDP;
however, attributes for these streams need not be present.

I think the confusion here may be around the word "session", which has 
two possible meanings in this context:
- an SDP session
- a signaling (e.g., SIP) session

This isn't entirely clear in the text, but it is widely understood that 
for SIP this is to be a SIP session. (Specifically, an INVITE dialog usage.)

> 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.

This is probably true. But since the 2nd offer was in error there is no 
good way to define what the proper behavior should be.

Thanks,
Paul

> Hope this helps to you.
>
> snippet from RFC 3264,
>
> 6 Generating the Answer
>
> .
> .
>   For each "m=" line in the offer, there MUST be a corresponding "m="
> line in the answer.  The answer MUST contain exactly the same number
> of "m=" lines as the offer.  This allows for streams to be matched up
> based on their order.  This implies that if the offer contained zero
> "m=" lines, the answer MUST contain zero "m=" lines.
>
> .
> .
> .
>
> Thanks and regards,
> -Praveen
>
>
>
> On Fri, Jan 10, 2014 at 12:11 PM, isshed  wrote:
>
>> 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 PCMA/8000
>>a=rtpmap:97 iLBC/8000
>>m=video 51372 RTP/AVP 31 32
>>a=rtpmap:31 H261/9
>>a=rtpmap:32 MPV/9
>>
>>
>>  [Answer From B]
>>
>>v=0
>>o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
>>s=
>>c=IN IP4 host.biloxi.example.com
>>t=0 0
>>m=audio 49172 RTP/AVP 0 8
>>a=rtpmap:0 PCMU/8000
>>a=rtpmap:8 PCMA/8000
>>m=video 0 RTP/AVP 31
>>a=rtpmap:31 H261/9
>>
>>  [Second-Offer From B]
>>
>>v=0
>>o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
>>s=
>>c=IN IP4 host.atlanta.example.com
>>t=0 0
>>m=audio 51372 RTP/AVP 0
>>a=rtpmap:0 PCMU/8000
>>
>>  [Second-Answer From A]
>>
>>v=0
>>o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
>>s=
>>c=IN IP4 host.biloxi.example.com
>>t=0 0
>>m=audio 49172 RTP/AVP 0
>>a=rtpmap:0 PCMU/8000
>>m=video 0 RTP/AVP 31
>>a=rtpmap:31 H261/9
>>
>>
>> Is it a valid offer answer model, as   [Second-Offer From B] removes
>> one of the m line?
>>
>> Thanks.
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] sip info message body CRLF

[Paul Kyzivat]

On 12/18/13 4:51 AM, iancu laura wrote:
>
> Hi,
>
> I am a newcomer to Sip and i want to clarify something from RFC 3261.
>
> I would like to know if,for a SIP INFO method, CRLF is mandatory at the end 
> of each line. Should the syntax of Info be with or without CRLF at the end of 
> message body?
>
> To be more clear, on the sip info there is no "0a 0d" at the end of the 
> message body and, for this reason from peer side we receive 400 bad request 
> with the reason "syntax error".is this a problem at the peer side with the 
> parser?or we should add 0a 0d at the end of message body line?
>>From my point of view, if this is not very clear mentioned in the protocol, a 
>>vendor can have it.s own design.
>
> Thank you in advance,
> Laura

This depends on the Content-Type of the body.
The body must conform to the Content-Type declared for it.
Some content types may require CRLF and others may not.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Contact binding cleanup

[Paul Kyzivat]

On 12/5/13 12:11 PM, Brett Tate wrote:
>> But if the tablet is still connected, you are likely
>> to get into a fight between the two devices. The tablet
>> will presumably reregister when it thinks its current
>> registration is going to expire. And if it follows
>> the same logic, it then might decide to unregister
>> your phone. I doubt that is what you want.
>>
>> Note that the existing registered devices typically
>> won't learn immediately that they have been unregistered.
>> But if they want to know that right away they can
>> discover it be subscribing to the registration event
>> package.
>
> The fight over subscriptions can be just as bad (i.e. subscription recreation 
> loop).  More specifically if the server doesn't allow an unlimited number of 
> simultaneous subscriptions for a particular event package, it will need to 
> decide what to do.  If the server terminates an old subscription because 
> allowing a new subscription, the device owning the old subscription might 
> create another subscription, again, again, ... if NOTIFY sent when 
> terminating the subscription.

I haven't heard of an event server that would so severely limit the 
number of subscriptions. In any case that is irrelevant to the current 
discussion.

And having the subscription only allows the registration fight to 
proceed more rapidly. :-)

If you want to have a policy of only one device registered at a time, 
then I think it will be necessary to have some additional mechanism to 
mediate between competing devices.

Perhaps you could have each device only refresh its registration if 
there is nothing else registered.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Contact binding cleanup

[Paul Kyzivat]

On 12/5/13 10:34 AM, Greg Burrow wrote:
> Paul,
>
> Thanks for the answers.  The client restart use case would normally
> reuse the same contact binding (IP address and sip.instance).  But what
> about the use case where a client attempts to de-register another
> clients contact binding.
>
> For example, I have a client running on my tablet.  It has registered
> and has one contact binding.  Then I start my smart phone client and it
> registers (same AOR) and receives its contact binding and the tablet
> contact binding in the 200OK.  Would it be possible for the smart phone
> to de-register the tablet contact binding?

It is *possible* for the phone to deregister the tablet.
You might even consider it a feature.

But if the tablet is still connected, you are likely to get into a fight 
between the two devices. The tablet will presumably reregister when it 
thinks its current registration is going to expire. And if it follows 
the same logic, it then might decide to unregister your phone. I doubt 
that is what you want.

Note that the existing registered devices typically won't learn 
immediately that they have been unregistered. But if they want to know 
that right away they can discover it be subscribing to the registration 
event package.

Thanks,
Paul

> Thanks,
>
> Greg
>
>
> On Wed, Dec 4, 2013 at 3:52 PM, Paul Kyzivat  <mailto:pkyzi...@alum.mit.edu>> wrote:
>
> On 12/4/13 4:34 PM, Greg Burrow wrote:
>  > Hello,
>  >
>  > After initial registration, the subscribers AOR has a single contact
>  > binding assigned in the registrar.  If the client crashes and then
>  > recovers, it will re-register and the 200OK will contain the previous
>  > contact binding along with the new binding.
>
> What you say is true *if* the client uses a different contact for the
> new binding. If it uses the old contact again, then not.
>
>  > In this case is it recommended for the client to de-register the
> previous
>  > binding?
>
> If you have some way to know with certainty that the old binding is
> yours, and not for some other UA, then it is ok and perhaps wise to
> do this.
>
> If you are not certain, then it's a bad idea.
>
>  > Can this be done by explicitly listing the old contact binding
>  > (with exipres=0)
>
> yes.
>
>  > or does the de-register need to use contact='*', remove
>  > all bindings, and force the client to re-register?  If the client
> has a new
>  > IP address after recovery from a crash (and a new sip.instance
> value), can
>  > the old binding still be removed?
>
> If you are using RFC 5626 then things get a little more complex.
>
> Why would you have a new sip.instance value? The whole point is that
> those should be stable over time.
>
>  Thanks,
>  Paul
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Contact binding cleanup

[Paul Kyzivat]

On 12/4/13 4:34 PM, Greg Burrow wrote:
> Hello,
>
> After initial registration, the subscribers AOR has a single contact
> binding assigned in the registrar.  If the client crashes and then
> recovers, it will re-register and the 200OK will contain the previous
> contact binding along with the new binding.

What you say is true *if* the client uses a different contact for the 
new binding. If it uses the old contact again, then not.

> In this case is it recommended for the client to de-register the previous
> binding?

If you have some way to know with certainty that the old binding is 
yours, and not for some other UA, then it is ok and perhaps wise to do this.

If you are not certain, then it's a bad idea.

> Can this be done by explicitly listing the old contact binding
> (with exipres=0)

yes.

> or does the de-register need to use contact='*', remove
> all bindings, and force the client to re-register?  If the client has a new
> IP address after recovery from a crash (and a new sip.instance value), can
> the old binding still be removed?

If you are using RFC 5626 then things get a little more complex.

Why would you have a new sip.instance value? The whole point is that 
those should be stable over time.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Media description with no c= but port = 0

[Paul Kyzivat]

On 12/2/13 4:49 AM, Stephen.Paterson wrote:
> Hi all,
>
> I'm sending an INVITE with two m= lines, one audio, one video. The response I 
> receive only accepts the audio stream - port = 0 for the video related m= 
> line.
> There is no global connection address and the audio description does contain 
> a c= line. The video description does not.
>
> As far as I can tell, a c= line is mandatory regardless of whether the port 
> is zero or not but I can't think of any problem with accepting it anyway as 
> the video is being rejected and the audio description is fine.
> Can anyone think of any possible problems if I accept this SDP? Or perhaps 
> point me to the spec that says this is fine if I've missed something? It is 
> the simplest of changes for me to allow it but at the moment I'm clearing the 
> call down which seems a bit harsh.

I would accept it. I can't see any good reason not to do so.

Thanks,
Paul

> Cheers
>
> Stephen Paterson
> Senior Developer   |  SYNETY
> www.synety.com
>
> ddi:01134 166029
> main: 0330 335 
>
> SMARTER COMMUNICATIONS
> Confidentiality: This e-mail transmission, including any attachments, is 
> intended only for the named recipient(s) and may contain information that is 
> privileged, confidential and/or exempt from disclosure under applicable law. 
> If you have received this transmission in error, or are not the named 
> recipient(s), please notify the sender immediately by return e-mail and 
> permanently delete this transmission, including any attachments.
>
> Security: This e-mail and any attachments are believed to be free from any 
> virus but it is the responsibility of the recipient to ensure this is so. 
> E-mail is not a 100% secure communications medium. We recommend you observe 
> this when e-mailing us.
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] changing the Direction Attributes.

[Paul Kyzivat]

On 11/26/13 9:06 PM, ankur bansal wrote:
> Hi Aditya
>
> I think this is valid from protocol and offer answer model .But its
> actually driven by use-case.
>
> *Usecase 1* :Normally during call(sendrecv :media flowing both ways) if
> we put call on hold (no music on hold) with inactive
> then *while resuming ,we put sendrecv*.
>
> *Usecase 2* :But for the scenario where media flowing one way(sendonly)
> like Video Share or Image Share from User A to User B
>And call is put on hold using inactive then*while
> resuming will put sendonly* again .
>
> *Usecase 3 *: *With MOH *
>
> User A(sendrecv) <In call-- >  User
> B(sendrecv)
>
> A holds(sendonly)--one way hold(MOH)- - >   User
> B(recvonly) listening to music
>
> A(inactive) <--2 way hold---
> User B holds(inactive)

So far so good. But I have issues below.
Again, please read RFC 6337, especially sections 5.3 and 5.1.

> *Now 2 cases possible depending who resumes firs*t
>
> *When A resume first:*

A had initiated hold, and now wants to resume. A's desired state is 
sendrecv.

> A resumes(recvonly)--still call held from B- -
>  >   User B(sendonly)

So A above should offer sendrecv, since that is his desired state, 
regardless of what B wanted.

Assuming B still wants to be on hold, it should then probably respond 
with sendonly, doing MOH. The end state is same as yours, but the means 
are different.

> A(sendrecv) <--Both way active--
> User B resumes(sendrecv)

Yes.

> *When B resume first:*

In this case B presumably wants sendrecv.

> A (sendonly) <--still call held from A- - ---
> User B resumes (recvonly)

So B should offer what it wants (sendrecv). Assuming A still wants to be 
on hold, then A will answer sendonly for MOH.

> A resumes(sendrecv) -Both way
> active--> User B (sendrecv)
>
>
> *So while resuming call , both users putting recvonly.*

As I showed above, it works as well in these cases to resume using 
sendrecv, and it is safer. You really never know what is going on at the 
other end, so you should make no assumptions about the other end when 
you generate your offer. The other end can deal with what it wants in 
the answer.

Thanks,
Paul

> Hope this helps
>
> Regards
> Ankur Bansal
>
>
> On Mon, Nov 25, 2013 at 6:30 AM, Paul Kyzivat  <mailto:pkyzi...@alum.mit.edu>> wrote:
>
> On 11/24/13 10:21 PM, Aditya Kumar wrote:
>  > Hi,
>  > Is the following valid.
>  > A keeps B on Hold with SDP -inactive. state on both sides
> offer-answer is inactive.
>  > Can A send again offer with SDP as (sendonly)--?. is this valid?
>  > if so can you plesae point me the reference/
>
> See RFC 6337, especially sections 5.3 and 5.1.
>
>  Best wishes,
>  Paul
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] changing the Direction Attributes.

[Paul Kyzivat]

On 11/24/13 10:21 PM, Aditya Kumar wrote:
> Hi,
> Is the following valid.
> A keeps B on Hold with SDP -inactive. state on both sides offer-answer is 
> inactive.
> Can A send again offer with SDP as (sendonly)--?. is this valid?
> if so can you plesae point me the reference/

See RFC 6337, especially sections 5.3 and 5.1.

Best wishes,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Tel URL in Contact header of Register request

[Paul Kyzivat]

On 11/18/13 11:31 PM, Vivek Gupta wrote:
> RFC section 10.2.1 says below:
>
> The Contact header field values of the request typically consist of SIP or
> SIPS URIs that identify particular SIP endpoints (for example, “
> sip:ca...@cube2214a.chicago.com”), but they MAY use any URI scheme.* A **SIP
> UA can choose to register telephone numbers (with the tel URL, RFC 2806
> [8]) or email addresses (with a mailto URL, RFC 2368 [32]) as Contacts for
> an address-of-record, for example.*
>
> I would be interested to know the practical use cases where SIP UA would
> make use of Tel URL in the Contact header when registering.

A UA that is registering isn't necessarily registering contacts that 
identify itself. It may register contacts that identify something else. 
You could potentially register a TEL uri in order to get incoming calls 
redirected to some arbitrary phone number.

Thanks,
Paul

> Vivek Gupta | Sr. Consultant Engineering
> GlobalLogic
> P +91.120.406.2953  M +91.987.390.4358  S vivek.gupta_globallogic.com
> www.globallogic.com
>   
> http://www.globallogic.com/email_disclaimer.txt
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Expected response for UPDATE request sent after 200OK of INVITE request

[Paul Kyzivat]

On 10/29/13 11:39 AM, Sourav Dhar Chaudhuri wrote:
> Hi,
> Thanks for your response.
>
>   In this case UAS has received UPDATE request before receiving the ACK 
> for the INVITE.
>
>
>In  my case UAS is not sending any response for that UPDATE.

That is totally wrong. Every request must get a final response.

> So my question is that  What will be the response for this UPDATE? I have 
> found one testcase in the link 
> https://www.cisco.com/en/US/docs/ios-xml/ios/voice/sip/configuration/15-mt/voi-sip-rfc.html#GUID-0C33CD1F-D738-481D-BC59-34A782986D4A

This is just Cisco's opinion.

> I have not found any supported link in any RFC  the behavior mentioned in 
> that link.
>
>
> Error Responses to UPDATE Request Processing Before the Call Is Active

There is no error! So you shouldn't be looking for an error response.

I'm not sure what "Call Is Active" means above. But UPDATE *can* be used 
before the call is *answered*. (But not in this case. It can be used to 
send a subsequent offer once an answer has been received in a reliable 
provisional response.)

You already sent a 200 response to an identical offer earlier.
So I presume it is still acceptable to you. So you should probably be 
sending a 200 response. What you put in the answer is up to you. The 
most obvious is to include the same answer you did before. But you may 
answer differently if you wish.

> In other scenarios, additional rules apply to processing an UPDATE request 
> with an offer when the gateway has sent a 200 OK response to an INVITE 
> request but has not yet received an ACK. The following scenarios generate an 
> error response and are shown in the figure below:
>   *  If the initial INVITE request contains an offer but does not require 
> provisional responses be sent reliably, then the SDP in the 200 OK is treated 
> like an answer. If the UAS then receives an UPDATE request before an ACK 
> response to the 200 OK, the UAS sends a 500 Server Internal error response 
> with a Retry-After header.

You certainly MAY do this if you wish.

>   *  If the initial INVITE does not contain an offer and does not require 
> provisional responses be sent reliably, then the SDP in the 200 OK is treated 
> like an offer. If the UAS then receives an UPDATE request before receiving an 
> ACK to the 200 OK, the UAS sends a 491 Request Pending response.

This doesn't apply to the case you have described.

> Figure 5. Error Cases for UPDATE Requests
>
>
>
>
>
> Due to that UAC is retransmitting UPDATE continuously and finally it is 
> terminating the dialog on not receiving any final response that UPDATE. This 
> is as per RFC 3311.

Of course the UAC is retransmitting the UPDATE, since you haven't 
responded to it.

Do you receive the ACK somewhere in here? (If you don't then the UAC is 
probably broken.)

Thanks,
Paul

> On Tuesday, 29 October 2013 7:53 PM, Paul Kyzivat  
> wrote:
>
> On 10/29/13 9:55 AM, Sourav Dhar Chaudhuri wrote:
>> Hi,
>>   I need the expected response for the Call scenario mentioned below
>>
>> 1)  UAC sends INVITE request with SDP
>>
>> 2)  UAS sends 180 ringing to UAC
>>
>> 3) Then UAS sends 200 OK  fo with SDP response INVITE .
>>
>> 4) Now after receiving 200 OK response by UAC. it generates UPDATE request  
>> with same SDP mentioned in STEP 1 towards UAS. Is it a valid behavior?
>>
>> 5) Now what should be the response  from  UAS for that UPDATE request ??
>>
>>  After sending the UPDATE request UAC has also also ACK request for 200 
>> OK response.
>
> The UAS is receiving the UPDATE before the ACK?
>
> The UPDATE seems silly, but not *wrong*.
>
> The UAS receiving the UPDATE before the ACK isn't proof that they were
> sent in that order. And even if they were it isn't really wrong as long
> as the ACK is sent in a timely way.
>
> As far as what the UAS should respond, this is a new offer. All the same
> rules apply as if it were sent long after the INVITE transaction completed.
>
>  Thanks,
>  Paul
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Expected response for UPDATE request sent after 200OK of INVITE request

[Paul Kyzivat]

On 10/29/13 9:55 AM, Sourav Dhar Chaudhuri wrote:
> Hi,
> I need the expected response for the Call scenario mentioned below
>
> 1)  UAC sends INVITE request with SDP
>
> 2)  UAS sends 180 ringing to UAC
>
> 3) Then UAS sends 200 OK  fo with SDP response INVITE .
>
> 4) Now after receiving 200 OK response by UAC. it generates UPDATE request  
> with same SDP mentioned in STEP 1 towards UAS. Is it a valid behavior?
>
> 5) Now what should be the response  from  UAS for that UPDATE request ??
>
>After sending the UPDATE request UAC has also also ACK request for 200 OK 
> response.

The UAS is receiving the UPDATE before the ACK?

The UPDATE seems silly, but not *wrong*.

The UAS receiving the UPDATE before the ACK isn't proof that they were 
sent in that order. And even if they were it isn't really wrong as long 
as the ACK is sent in a timely way.

As far as what the UAS should respond, this is a new offer. All the same 
rules apply as if it were sent long after the INVITE transaction completed.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Outgoing REFER but no support for incoming NOTIFY.

[Paul Kyzivat]

On 10/24/13 10:37 AM, Kumar, Puneet (Puneet) wrote:
> Hi All,
>
> I am seeing a case where UAC sends an in-dialog REFER but do not include 
> "Allow: NOTIFY".
> Due to this UAS is not able to send a NOTIFY with sipfrag back to UAC.
>
> Is this valid?
> What can be use case for not supporting NOTIFY?

Does the request include *any* Allow header field?

RFC 3261 says:

The absence of an Allow header field MUST NOT be
interpreted to mean that the UA sending the message supports no
methods.   Rather, it implies that the UA is not providing any
information on what methods it supports.

There is a mechanism (RFC 4488) for suppressing the implicit 
subscription from REFER. If that is used than no NOTIFY would be expected.

If the REFER does have an Allow without NOTIFY, and it doesn't disable 
the subscription, then it seems to be in error.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SDP Offer Answer Model

[Paul Kyzivat]

On 10/23/13 6:23 AM, Brett Tate wrote:
>> Also I want to know what should be the answer in this case ?
>
> Because the offer SDP is malformed, the device can basically act how it 
> wants.  Similarly, I assume that the behavior might vary based upon if 
> received within INVITE, UPDATE, PRACK, 18x, or 2xx.
>
> Some aspects are likely discussed within RFC 6337.
>
> A strict device would likely reject the INVITE or UPDATE (or PRACK depending 
> upon RFC 3262 interpretation) with a 400, 488, or 606.

Or you could be lenient. Because the port is zero, the PTs don't matter.
So you can treat it as a valid offer with a zero port.

Then, as I mentioned earlier, you still need to decide what you want to 
do. You can accept the call and see what happens, or you can reject it, 
probably with a 488 or 606.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SDP Offer Answer Model

[Paul Kyzivat]

I believe this is valid.
If accepted, you will have a signaling session, but no media.
That isn't terribly useful if it stays that way. But it might just be 
transitional, with an intent to send an updated offer later.

But the caller is risking that the callee will simply refuse the call. 
If there is a real user at the other end, he will get silence. At best 
he will wait awhile, and then hang up if things don't get better.

The caller here had better have some plans for what to do next. The 
callee certainly can't be expected to make a counter offer.

Thanks,
Paul

On 10/22/13 12:58 PM, isshed wrote:
> Hi all,
>
> Can there be an offer with as follows.
>
>v=0
>o=abc 940493389 1 IN IP4 10.10.10.10
>s=-
>c=IN IP4 10.10.10.10
>t=0 0
>m=audio 0 RTP/AVP
>
> Here m line does not have any payload format . Is this a valid offer?
> what is the use case of this offer?
>
> Thanks,
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SDP Offer Answer Model

[Paul Kyzivat]

On 10/22/13 1:17 PM, Brett Tate wrote:
>> Can there be an offer with as follows.
>>
>>v=0
>>o=abc 940493389 1 IN IP4 10.10.10.10
>>s=-
>>c=IN IP4 10.10.10.10
>>t=0 0
>>m=audio 0 RTP/AVP
>>
>> Here m line does not have any payload
>> format . Is this a validoffer?
>
> No.  It does not comply with RFC 4566 ABNF.

Ah. Sorry. I thought the point of the question was the zero port.
Brett is right (as always) that you need some payload type even with a 
zero port.

Sorry,
Paul

> media-field = %x6d "=" media SP port ["/" integer]
>SP proto 1*(SP fmt) CRLF
>
>
>> what is the use case of this offer?
>
> Torture test.


___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] sip device ring back tone

[Paul Kyzivat]

On 10/9/13 11:37 AM, Despina Kitsou wrote:
>
> Hello,
>
> 180 and 183 have the same To-Tag, the first one contain SDP and connects
> early media (announcement/in-band) that A-side SIP device hears, but no
> indication that announcement has stop is received, then 180 Ringing
> without SDP is received from A-side SIP device but the device does not
> generates local ring back tone.
> Is it a limitation of the device if it does not generate local ring back
> tone in that case,

Yes, I would consider this a limitation of the device.
Its not really a violation, because there aren't any formal rules about 
what must be done in these cases. (The device isn't required to render 
*anything*.)

> is a 199 needed in this case since we have one dialog??

A 199 would be incorrect in this case.

> Also according to standards  180 Ringing without SDP will trigger local
> ring back tone
> RFC3960:

Note that RFC3960 is *informational*, it is not normative.
It provides suggestions.

> With this in mind, a UAC should develop its local policy regarding
> local ringing generation.  For example, a POTS ("Plain Old Telephone
> Service")-like SIP User Agent (UA) could implement the following
> local policy:
>
>1. Unless a 180 (Ringing) response is received, never generate
>   local ringing.
>
>*2. If a 180 (Ringing) has been received but there are no incoming
>   media packets, generate local ringing.*
>
>3. If a 180 (Ringing) has been received and there are incoming
>   media packets, play them and do not generate local ringing.
>
>   Note that a 180 (Ringing) response means that the callee is
>   being alerted, and a UAS should send such a response if the
>   callee is being alerted, regardless of the status of the early
>   media session.
>
>
> Is there a known limitation on sip devices that if an early-media inband
> information is connected ( in our case announcement) then afterwards it
> cannot generate local ringing???

I'd say its just not a very well implemented device.
You could complain to its developer. But it isn't obligated to behave 
better.

You could experiment with different ways of behaving, and see if you can 
find something that works better with it. But of course that might cause 
trouble with other devices.

Good luck,
Paul

> Thank you very much,
>
> Despina
>
>
>
>  > Date: Wed, 9 Oct 2013 11:10:52 -0400
>  > From: pkyzi...@alum.mit.edu
>  > To: sip-implementors@lists.cs.columbia.edu
>  > Subject: Re: [Sip-implementors] sip device ring back tone
>  >
>  > On 10/9/13 10:39 AM, Despina Kitsou wrote:
>  > >
>  > > Hello,
>  > >
>  > > I have the following issues regarding the :
>  > >
>  > > Firstly, A-SIP subscriber call to a TDM subscriber that has been
> ported now to a C-SIP subscriber.So A-SIP subscriber receives an 183
> Session progress with SDP in order for an announcement to be heard that
> this subscriber is ported and that you call is being diverted, then
> C-SIP subscriber is reached and sent 180 Ringing without SDP but my
> A-SIP device does not generate local ringing,
>  > > Is that a limitation of the sip device to Switch Between Early
> Media and Local Ringing???PLEASE HELP ME!!
>  >
>  > More detail would be helpful.
>  >
>  > Are the 183 and 180 on different early dialogs (different to-tags), or
>  > the same one?
>  >
>  > Does the early media from the 183 continue after the 180 is received, or
>  > does it stop?
>  >
>  > If its all on one early dialog, then it should be clear (based on the
>  > 180) to the caller that the call is ringing. While media is being
>  > received it should be played. If it stops, then the caller ought to
>  > generate local ringback.
>  >
>  > If these are on two different early dialogs, then it is tricky. The
>  > caller doesn't know which of the two dialogs will eventually be
>  > answered. It also doesn't know which dialog the media is coming from. So
>  > the device has to take a lot of discretion in what it does. There is no
>  > one right answer in this case. I'd be inclined to say it ought to behave
>  > the same as if there was only one early dialog.
>  >
>  > The callee could help this along a bit by returning a 199 () on
>  > the dialog containing the 183 to indicate that is done.
>  >
>  > Thanks,
>  > Paul
>  >
>  > ___
>  > Sip-implementors mailing list
>  > Sip-implementors@lists.cs.columbia.edu
>  > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] sip device ring back tone

[Paul Kyzivat]

On 10/9/13 10:39 AM, Despina Kitsou wrote:
>
> Hello,
>
> I have the following issues regarding the  :
>
> Firstly, A-SIP subscriber call to a TDM subscriber that has been ported now 
> to a C-SIP subscriber.So A-SIP subscriber receives an 183 Session progress 
> with SDP in order for an announcement to be heard that this subscriber is 
> ported and that you call is being diverted, then  C-SIP subscriber is reached 
> and sent 180 Ringing without SDP  but my A-SIP device does not generate local 
> ringing,
> Is that a limitation of the sip device to Switch Between Early Media and 
> Local Ringing???PLEASE HELP ME!!

More detail would be helpful.

Are the 183 and 180 on different early dialogs (different to-tags), or 
the same one?

Does the early media from the 183 continue after the 180 is received, or 
does it stop?

If its all on one early dialog, then it should be clear (based on the 
180) to the caller that the call is ringing. While media is being 
received it should be played. If it stops, then the caller ought to 
generate local ringback.

If these are on two different early dialogs, then it is tricky. The 
caller doesn't know which of the two dialogs will eventually be 
answered. It also doesn't know which dialog the media is coming from. So 
the device has to take a lot of discretion in what it does. There is no 
one right answer in this case. I'd be inclined to say it ought to behave 
the same as if there was only one early dialog.

The callee could help this along a bit by returning a 199 (RFC6228) on 
the dialog containing the 183 to indicate that is done.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] RFC 3325: addr-spec with parameters

[Paul Kyzivat]

On 10/4/13 9:39 AM, Balint Menyhart wrote:
> Hi,
>
> While we are here...
> RFC 3261's section 20 has obviously not been written in a
> forward-compatible way. Is there any hint in any subsequent standard
> document that requires the quoted paragraph to be applied to other
> similar-looking headers? Or is it just an assumption based on "we like
> things that look consistent"?
>
> Or to put it in a different way, if we see an implementation not adding
> the angle brackets in a name-addr / addr-spec extension header
> containing, say, a question mark, and the extension RFC does not
> verbatim include or refer to 2361's section 20, do we have any ground
> (subsequent RFC, best practice document, erratum, or something), other
> than our sense of aesthetics or consistency, to tell them off?

Probably not.

The real reason that the <> are needed has to do with the syntax of what 
follows the name-addr/addr-spec. If additional syntax would allow a 
character that would then be ambiguous then there is a problem. If the 
additional syntax doesn't introduce an inconsistency, then there is no 
problem.

Thanks,
Paul

> Thanks in advance,
> Balint
>
>
> On 03/10/2013 19:21, Brett Tate wrote:
>> Hi,
>>
>> Concerning RFC 3325's P-Asserted-Identity and P-Preferred-Identity, should 
>> the typical bracket rule apply concerning parameters?
>>
>> Since these headers do not contain parameters, I assume that the following 
>> RFC 3261 section 20 snippet does not apply.
>>
>> Thanks,
>> Brett
>>
>> -
>>
>> RFC 3261 section 20:
>>
>>The Contact, From, and To header fields contain a URI.  If the URI
>>contains a comma, question mark or semicolon, the URI MUST be
>>enclosed in angle brackets (< and >).  Any URI parameters are
>>contained within these brackets.  If the URI is not enclosed in angle
>>brackets, any semicolon-delimited parameters are header-parameters,
>>not URI parameters.
>>
>> RFC 3325 section 9.1:
>>
>>PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
>> *(COMMA PAssertedID-value)
>>PAssertedID-value = name-addr / addr-spec
>>
>> RFC 3325 section 9.2:
>>
>>PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value
>>   *(COMMA PPreferredID-value)
>>PPreferredID-value = name-addr / addr-spec
>>
>> This email is intended solely for the person or entity to which it is 
>> addressed and may contain confidential and/or privileged information. If you 
>> are not the intended recipient and have received this email in error, please 
>> notify BroadSoft, Inc. immediately by replying to this message, and destroy 
>> all copies of this message, along with any attachment, prior to reading, 
>> distributing or copying it.
>>
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] RFC 3325: addr-spec with parameters

[Paul Kyzivat]

On 10/3/13 2:21 PM, Brett Tate wrote:
> Hi,
>
> Concerning RFC 3325's P-Asserted-Identity and P-Preferred-Identity, should 
> the typical bracket rule apply concerning parameters?
>
> Since these headers do not contain parameters, I assume that the following 
> RFC 3261 section 20 snippet does not apply.

That rule needs to apply anywhere the ABNF allows
name-addr / addr-spec

Otherwise that rule is ambiguous.

> Thanks,
> Brett
>
> -
>
> RFC 3261 section 20:
>
>   The Contact, From, and To header fields contain a URI.  If the URI
>   contains a comma, question mark or semicolon, the URI MUST be
>   enclosed in angle brackets (< and >).  Any URI parameters are
>   contained within these brackets.  If the URI is not enclosed in angle
>   brackets, any semicolon-delimited parameters are header-parameters,
>   not URI parameters.
>
> RFC 3325 section 9.1:
>
>   PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
>*(COMMA PAssertedID-value)
>   PAssertedID-value = name-addr / addr-spec
>
> RFC 3325 section 9.2:
>
>   PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value
>  *(COMMA PPreferredID-value)
>   PPreferredID-value = name-addr / addr-spec
>
> This email is intended solely for the person or entity to which it is 
> addressed and may contain confidential and/or privileged information. If you 
> are not the intended recipient and have received this email in error, please 
> notify BroadSoft, Inc. immediately by replying to this message, and destroy 
> all copies of this message, along with any attachment, prior to reading, 
> distributing or copying it.
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors