Re: [Sip-implementors] Call hold with a=inactive

[Paul Kyzivat]

On 9/7/23 8:44 AM, Roman Shpount wrote:

No, A is not on hold. Placing on hold requires a user action. Unless the
user of A placed it on hold, A is not on hold. Anything done by B doesn't
affect A hold status.


+1

An offer should only be based on local preferences, because the other 
side can express its preferences in its answer. When one side conditions 
its offers based on what it *thinks* the other side wants that can lead 
to a "stuck on hold" situation.


Thanks,
Paul


_
Roman Shpount


On Thu, Sep 7, 2023 at 8:38 AM Sundbaum Per-Johan (Telenor Sverige AB) <
per-johan.sundb...@telenor.se> wrote:


But you could argue that also A is on hold after  “*3. A sends 200 ok
with a=inactive”  ?*

BR/pj




Sensitivity: Internal
From: Roman Shpount 
*Sent:* den 7 september 2023 14:26
*To:* Sundbaum Per-Johan (Telenor Sverige AB) <
per-johan.sundb...@telenor.se>
*Cc:* sip-implementors@lists.cs.columbia.edu
*Subject:* Re: [Sip-implementors] Call hold with a=inactive



A should respond with a=sendrecv. The A response (offer in 2XX response to
a re-INVITE) should depend on A hold status only. The state of B has no
effect on A offers. So, since A is not on hold, a=sendrecv is the most
appropriate answer.



On the other hand, if A sends a re-INVITE without SDP to B, B should
respond with a=inactive, since B is on hold.

_
Roman Shpount





On Thu, Sep 7, 2023 at 6:55 AM Sundbaum Per-Johan (Telenor Sverige AB) <
per-johan.sundb...@telenor.se> wrote:

Hi !

A question that I hope is simple for some helpful person to answer:

1. Call connected between A and B
2. B holds the call with re-INVITE a=inactive
3. A sends 200 ok with a=inactive
4. B sends re-INVITE without SDP

A should answer a=sendonly or is a=sendrecv normally a better option or
perhaps something else ?


MVH/pj



Sensitivity: Internal
___
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] How to differentiate Hold RTP and voice RTP

[Paul Kyzivat]

Arun,

On 9/22/22 10:56 AM, Arun Tagare wrote:

Thanks Ranjit,

Yes for the signalling part i am aware, but as shared earlier how the RTP
from N/w and other UE in same session be differentiate?

So SSRC will be different right?


*Nothing* is certain here!

The SSRC may be different, but not necessarily.

The IP of the media stream may change, but not necessarily.

Signaling *may* change the direction to sendonly, but not necessarily.

There are no rules for any of this. Lots of different implementations 
are possible. The answers you get here are generally what people have 
observed in the environments they are exposed to. A lot of this will be 
based on some widely deployed implementations. Whether any of those, and 
if so which, might apply to your environment is hard to say.


If figuring this out is important to you, then you need to monitor the 
environment you operate within. See if most calls have a consistent 
pattern, or one of a few consistent patterns. Then build to deal with 
what you find. And be prepared for the cases that don't fit your 
expectations.


Good luck,
Paul


On Thu, 22 Sep 2022 at 8:05 PM, Ranjit Avasarala 
wrote:


Hi Arun

Both are technically voice packets and use RTP protocol.  So that way both
are similar.  Also the voice traffic is end to end whereas hold music is
from the server.  Like announcement - may be from Application Server.  So
looking at the SSRC or Source in RTP Packets, you should be able to say
which entity is sending those packets.

Another way to check is the SDP.  for hold music,  the media attribute
will be sendonly.  where as for regular voice traffic it will sendrecv

Regards
Ranjit

On Thu, Sep 22, 2022 at 4:19 AM Amanpreet Singh <
amanpreeet.si...@gmail.com> wrote:


Arun, for what purpose would you like to inspect and differentiate the
hold
and audio RTP packets?
and based on the signaling messages, can't that be achieved.

Thanks,
Amanpreet Singh.


On Thu, Sep 22, 2022 at 12:30 PM Arun Tagare 
wrote:


Thanks Ranjit & Amanpreet, for your response

But my question is

MT <= Call Established ===> MO
MT <===> Voice RTP Packets flow <=> MO
MT <==Hold ===> MO
MT < HOLD Tone RTP packets == NW

Both Voice RTP packets and Hold RTP packets come to the same port right

?

How to differentiate these RTP packets

On Thu, Sep 22, 2022 at 11:06 AM Amanpreet Singh <
amanpreeet.si...@gmail.com> wrote:


Probably you can think of looking into the signaling messages(SDP in

case

of SIP) to differentiate when the call is on hold and when not i.e.

normal

audio RTP.

BTW what is the use case to differentiate call hold vs audio RTP?


Regards,
Amanpreet Singh.


On Wed, Sep 21, 2022 at 9:51 PM Arun Tagare 
wrote:


Hi All,

I have a doubt on the Hold call tone or music on hold tone RTP v/s

actual

voice RTP before hold

Can these RTP packets be able to differentiate?
If yes how?
if not why?

Thanks a lot to everyone in advance

--

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





--

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


--


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


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

Re: [Sip-implementors] Sip From header without user part

[Paul Kyzivat]

On 8/4/22 11:09 AM, Rakesh wrote:

Hi Paul,

Thanks for your response.
Quoting your statement "But it makes no sense to send this unless there 
was a matching prior sip request with the same sip URI."


If I understood correctly the earlier request prior to CANCEL is 
normally a sip INVITE. And in case of INVITE has been sent with the such 
format in FROM header then further requests like CANCEL can send it else 
not.


Do we have any reference on RFC that any SIP entity should not send sip 
 From header as like on CANCEL if INVITE has not sent with that way?


Spend some time understanding section 9 of RFC 3261.

It doesn't say it is incorrect to send a CANCEL without a prior matching 
request. But it specifies what the receiver of the CANCEL should do - 
that it should send a 481 response.


From what little you have said about the situation it sounds like this 
may have been sent as part of a test. If so the sender may intentionally 
be generating error cases to see if your implementation responds to them 
as it should.


Thanks,
Paul


BR///Rakesh

On Thu, Aug 4, 2022 at 8:24 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:


On 8/4/22 8:11 AM, Rakesh wrote:
 > Hi Team,
 >
 > I could see in a sip CANCEL message From Header as below
 >
 > From: "test" http://ims.test.in>>;tag=3bbb9483d215d830c635372f8f181929
 >
 > is this correct?

Just looking at this, without regard for context, it is valid syntax.
(The userinfo portion of the sip URI is optional.)

But it makes no sense to send this unless there was a matching prior
sip
request with the same sip URI.

Each domain is free to define the userinfo portion of its sip URIs
as it
sees fit. This includes whether to support URIs with no userinfo. You
might want to consult an administrator for ims.test.in
<http://ims.test.in>.

         Thanks,
         Paul

 > Normally the From header is sip:user@domain
 >
 > As per ABNF grammar, the above one is also should not be an issue
as From
 > header but could let me know if I misinterpreted the ABNF grammar?
 >
 > BR///Rakesh
 > ___
 > 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
<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
<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 From header without user part

[Paul Kyzivat]

On 8/4/22 8:11 AM, Rakesh wrote:

Hi Team,

I could see in a sip CANCEL message From Header as below

From: "test" ;tag=3bbb9483d215d830c635372f8f181929

is this correct?


Just looking at this, without regard for context, it is valid syntax. 
(The userinfo portion of the sip URI is optional.)


But it makes no sense to send this unless there was a matching prior sip 
request with the same sip URI.


Each domain is free to define the userinfo portion of its sip URIs as it 
sees fit. This includes whether to support URIs with no userinfo. You 
might want to consult an administrator for ims.test.in.


Thanks,
Paul


Normally the From header is sip:user@domain

As per ABNF grammar, the above one is also should not be an issue as From
header but could let me know if I misinterpreted the ABNF grammar?

BR///Rakesh
___
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] CSeq in subsequent Register messages

[Paul Kyzivat]

On 6/28/22 4:19 AM, Gilson Urbano Ferreira Dias wrote:

Dale,

The three pseudo-dialogs are for different AORs.


It would be very helpful if you would post the full messages.

Thanks,
Paul


Does this change anything in the analysis?

Regards,

Gilson Urbano
___
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 REGISTER MESSAGE flow

[Paul Kyzivat]

Arun,

Your query doesn't have enough context to understand the case. It does 
however appear to more likely to be something that should be answered by 
someone in the 3GPP IMS community. If you want an answer here please 
spell out your case in much more detail.


Thanks,
Paul

On 11/20/21 1:59 AM, Arun Tagare wrote:

Hi Team,

Need some info, can UE be allowed (as per rule) to send SIP REGISTER
requests to all the received P-CSCF addresses from NW (during attach) ?

For Ex.
If UE received 5 P-CSCF address during attach

Is it allowed to send REG to address at the same time
UE REG to P-CSCF-1--->
UE REG to P-CSCF-2--->
UE REG to P-CSCF-3--->
UE REG to P-CSCF-4--->
UE REG to P-CSCF-5--->

<--- 401 from P-CSCF-2
<--- 401 from P-CSCF-3
<--- 401 from P-CSCF-5

UE AUTH-REG to P-CSCF-2--->
UE AUTH-REG to P-CSCF-3--->
UE AUTH-REG to P-CSCF-5--->

<-- 200 OK from P-CSCF-5

So, UE finally connected to P-CSCF-5
I know this may increase signalling load on NW, but want to understand is
this flow allowed as per rules ? Or there are any restrictions please help
on understanding





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

Re: [Sip-implementors] RFC 4028 UAS behavior requirement of Require header

[Paul Kyzivat]

Ranjit,

BTW, did you notice that there is an erata applying to section 9 of 
RFC4028? If you didn't notice, it might be confusing you.


On 5/28/21 5:59 PM, Paul Kyzivat wrote:

On 5/28/21 4:40 PM, Ranjit Avasarala wrote:

Hi Holi

The RFC says UAS should add a Require: timer in response when UAC is the
refresher to indicate to UAC that it is the refresher. But I think 
this is

redundant as UAC anyway knows it is the refresher and does not need a
reminder from UAS.


The UAC makes an offer with Supported:timer and refresher=uac. That says 
it is *willing* to use timer, and is needs to be the refresher *if* 
timer is used for this call. At that point it is still uncertain whether 
timer will be used.


In the case where the UAS does support timer, it consummates the 
negotiation by including Require:timer and including refresher=uac as 
confirmation. It is the Require:timer that is the action that confirms 
timer is to be used. The refresher=uac is pro forma per Table 2 in that 
there is no choice in this case. But the UAC has to say *something* 
about it in the Session-Expires field.


 Thanks,
 Paul


On Fri, May 28, 2021 at 3:18 PM Hoil Choi  wrote:


Hi Ranjit, thanks for taking a look.

However, I'm more interested in case where UAS is responding to UAC's
request with refresher as itself (uac).  Consider this case -

UAC  INVITE (Session-Expires: 1800;refresher=uac, Supported: timer)
> UAS
UAC < 200 OK (Session-Expires: 1800;refresher=uac)
- UAS

In this case, the statement in question seems to convey that UAS should
also add "Require: timer" in its 200 response.  Why would this be, when
it's clear that UAC declared itself as the refresher and that timer is
supported?

For reference, RFC 4028 Section 9 UAS Behavior (or page 16)
If the refresher parameter in the Session-Expires header field in the 
2xx

response has a value of 'uac', the UAS MUST place a Require header field
into the response with the value 'timer'.

Thanks,
Hoil

--
*From:* Ranjit Avasarala 
*Sent:* Friday, May 28, 2021 12:38 PM
*To:* Hoil Choi ;
Sip-implementors@lists.cs.columbia.edu <
Sip-implementors@lists.cs.columbia.edu>
*Cc:* sipc...@ietf.org 
*Subject:* Re: [sipcore] RFC 4028 UAS behavior requirement of Require
header

Hi Holi
the presence of the "Require" header with value "timer" from UAS 
indicates
to UAC that it (UAC) is performing the refreshing operation. but if 
the UAS
is the refresher, then if Require header with value "timer" is 
present in

response from UAS, then UAC should send BYE if it does not receive a
session refresh request from UAS.

Regards
Ranjit



On Fri, May 28, 2021 at 10:02 AM Hoil Choi  
wrote:


Hello,

I hope this mail finds appropriate person or team for an answer to my
question on RFC 4028.
I am a SIP enthusiast and always learning a lot about it, but by no 
means

am I an expert; so please excuse my ignorance.

I came across an interesting statement In Section 9 UAS Behavior (or 
page

16).


If the refresher parameter in the Session-Expires header field in the
    2xx response has a value of 'uac', the UAS MUST place a Require
    header field into the response with the value 'timer'.


Statement seems to convey that UAS must place a Require header with 
value

'timer' when UAC requests itself to be the refresher.

However, this statement should only be true, if UAC did not put
Session-Expire with value of 'uac'.

If UAC, in INVITE request, put Session-Expire with value of 'uac'
(itself), UAS should not bother putting Require header field in the
response.  Or to be more accurate, UAC should include 'timer' in 
Supported

header, so that UAS doesn't have to bother putting Require header field.

What is the reason behind the requirement of Require header, from UAS in
this case?

Thanks!
Hoil Choi
253-273-5442

___
sipcore mailing list
sipc...@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore=04%7C01%7C%7C4f68f91aa77847f0fb6508d922102eb4%7C84df9e7fe9f640afb435%7C1%7C0%7C637578275155641932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=3McfrKwjz9RwC%2FBRLtdyopgzmNmUqsAKdAXyyRvChuc%3D=0> 





___
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] [sipcore] RFC 4028 UAS behavior requirement of Require header

[Paul Kyzivat]

On 5/28/21 4:40 PM, Ranjit Avasarala wrote:

Hi Holi

The RFC says UAS should add a Require: timer in response when UAC is the
refresher to indicate to UAC that it is the refresher. But I think this is
redundant as UAC anyway knows it is the refresher and does not need a
reminder from UAS.


The UAC makes an offer with Supported:timer and refresher=uac. That says 
it is *willing* to use timer, and is needs to be the refresher *if* 
timer is used for this call. At that point it is still uncertain whether 
timer will be used.


In the case where the UAS does support timer, it consummates the 
negotiation by including Require:timer and including refresher=uac as 
confirmation. It is the Require:timer that is the action that confirms 
timer is to be used. The refresher=uac is pro forma per Table 2 in that 
there is no choice in this case. But the UAC has to say *something* 
about it in the Session-Expires field.


Thanks,
Paul


On Fri, May 28, 2021 at 3:18 PM Hoil Choi  wrote:


Hi Ranjit, thanks for taking a look.

However, I'm more interested in case where UAS is responding to UAC's
request with refresher as itself (uac).  Consider this case -

UAC  INVITE (Session-Expires: 1800;refresher=uac, Supported: timer)
> UAS
UAC < 200 OK (Session-Expires: 1800;refresher=uac)
- UAS

In this case, the statement in question seems to convey that UAS should
also add "Require: timer" in its 200 response.  Why would this be, when
it's clear that UAC declared itself as the refresher and that timer is
supported?

For reference, RFC 4028 Section 9 UAS Behavior (or page 16)
If the refresher parameter in the Session-Expires header field in the 2xx
response has a value of 'uac', the UAS MUST place a Require header field
into the response with the value 'timer'.

Thanks,
Hoil

--
*From:* Ranjit Avasarala 
*Sent:* Friday, May 28, 2021 12:38 PM
*To:* Hoil Choi ;
Sip-implementors@lists.cs.columbia.edu <
Sip-implementors@lists.cs.columbia.edu>
*Cc:* sipc...@ietf.org 
*Subject:* Re: [sipcore] RFC 4028 UAS behavior requirement of Require
header

Hi Holi
the presence of the "Require" header with value "timer" from UAS indicates
to UAC that it (UAC) is performing the refreshing operation. but if the UAS
is the refresher, then if Require header with value "timer" is present in
response from UAS, then UAC should send BYE if it does not receive a
session refresh request from UAS.

Regards
Ranjit



On Fri, May 28, 2021 at 10:02 AM Hoil Choi  wrote:

Hello,

I hope this mail finds appropriate person or team for an answer to my
question on RFC 4028.
I am a SIP enthusiast and always learning a lot about it, but by no means
am I an expert; so please excuse my ignorance.

I came across an interesting statement In Section 9 UAS Behavior (or page
16).


If the refresher parameter in the Session-Expires header field in the
2xx response has a value of 'uac', the UAS MUST place a Require
header field into the response with the value 'timer'.


Statement seems to convey that UAS must place a Require header with value
'timer' when UAC requests itself to be the refresher.

However, this statement should only be true, if UAC did not put
Session-Expire with value of 'uac'.

If UAC, in INVITE request, put Session-Expire with value of 'uac'
(itself), UAS should not bother putting Require header field in the
response.  Or to be more accurate, UAC should include 'timer' in Supported
header, so that UAS doesn't have to bother putting Require header field.

What is the reason behind the requirement of Require header, from UAS in
this case?

Thanks!
Hoil Choi
253-273-5442

___
sipcore mailing list
sipc...@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore




___
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] 400 BadRequest

[Paul Kyzivat]

On 2/23/21 1:53 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

Hi !
I had to hide some customer related info, but otherwise the request is now 
complete.
(I don't know of any way to provide a wireshark trace without revealing 
customer information, I have not yet found a way to recreate the problem with 
my test equipment)


That is a lot. Based on a superficial scan it looks ok to me. I don't 
see reason to return 400. Again, if the reason argued is that 
preconditions are supported but not used, that doesn't justify the result.


Thanks,
Paul


-
INVITE tel:+46x SIP/2.0
Headers
To: tel:+46x
From: "46x" 
;tag=p65541t1611061049m518776c21142s1_1637070712-698561741
Call-ID: p65541t1611061049m518776c21142s2
CSeq: 1 INVITE
Max-Forwards: 66
Content-Length: 754
Via: SIP/2.0/TCP 
10.49.247.85:5060;branch=z9hG4bK41638c83800fcb7a519a2b35198b6d9dk55yacabaaa3Zqkv7ad0qlnsabaaiaqacqaa
Via: SIP/2.0/TCP 10.49.247.89:5160;branch=z9hG4bK1637070684-451807432
Route: 
Record-Route: 

Contact: sip:p65541t1611061049m518776c21142s1@10.49.247.89:5160
Content-Type: application/sdp
Call-Info: ;appearance-index=1
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, UPDATE, INVITE, ACK, 
OPTIONS, CANCEL, BYE
Accept: application/btbc-session-info
Accept: application/media_control+xml
Accept: application/sdp
Accept: application/x-hotsip-filetransfer+xml
Accept: multipart/mixed
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Supported: timer, 100rel, precondition
P-Asserted-Identity: "xxx " 
P-Asserted-Identity: "46x" 
Min-SE: 120
Session-Expires: 1800
Privacy: none
P-Charging-Vector: 
icid-value=pmp6.pcscf2.ims2.se.telenor.ne-1611-61048-962721-664;icid-generated-at=pmp6.pcscf2.ims2.se.telenor.net;orig-ioi=ims2.se.telenor.net
User-Agent: Ericsson MTAS - CXP2010134/1 R19C12
P-Charging-Function-Addresses: 
ccf="aaa://europolitan.se";ccf="aaa://riga.europolitan.se"
Diversion: 
"46x";reason=unknown;counter=4;answered-count=1;diversion-inhibited
Diversion: 
"46x";reason=unknown;counter=1;answered-count=1
Feature-Caps: *;+g.3gpp.ics
P-Early-Media: supported
Recv-Info: x-broadworks-client-session-info
Session-ID: 5305512bc6106ff4a4056d007a0155dc
Body
SDP PDU
v=0
o=- 805530524834577 1881693955 IN IP4 10.49.247.89
s=-
c=IN IP4 10.49.24.132
t=0 0
a=sendrecv
m=audio 34004 RTP/AVP 104 110 111 9 102 108 8 105 100
b=AS:158
b=RS:612
b=RR:1837
a=rtpmap:104 AMR-WB/16000
a=fmtp:104 mode-change-capability=2; max-red=220
a=rtpmap:110 AMR-WB/16000
a=fmtp:110 octet-align=1; mode-change-capability=2; max-red=220
a=rtpmap:111 EVS/16000
a=fmtp:111 max-red=0
a=rtpmap:9 G722/8000
a=rtpmap:102 AMR/8000
a=fmtp:102 mode-change-capability=2; max-red=220
a=rtpmap:108 AMR/8000
a=fmtp:108 octet-align=1; mode-change-capability=2; max-red=220
a=rtpmap:8 PCMA/8000
a=rtpmap:105 telephone-event/16000
a=fmtp:105 0-15
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:20
a=maxptime:40
a=sendrecv
-

BR/pj


Sensitivity: Internal

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
 On Behalf Of Paul Kyzivat
Sent: den 23 februari 2021 17:41
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 400 BadRequest

On 2/22/21 9:09 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

Hi again !
Correction, there are of course not any "require: 100Rel" in INVITE, sorry I 
mixed things up !
BR/pj


We have a vendor that is saying that they correctly answers initial INVITE with 400 BadRequest 
because the INVITE have SIP header "supported: precondition" and also required: 
100rel", but not the equivalent QOS parameters in SDP.

Personally I think that this behavior is definitely against the "spirit" of 
SIP, but is it really in accordance with 3GPP 24.229  ?


I won't comment on 3gpp-specific aspects. But from a pure sip perspective I see 
nothing wrong with declaring supported:precondition but choosing not to 
negotiate any preconditions at that time. There is a distinction between 
support and use.

Based on your stated facts, and assuming there was nothing else wrong, IMO the 
UAS should have processed the incoming request.

If you post the full request then it should be possible to be more definitive 
about this. (The link you posted below doesn't work for me.)

Thanks,
Paul


"The MSC sends 400 Bad Request because the received SIP Invite has precondition 
in the header part but no precondition related attributes in the SDP part.

This behavior is according to Function Specification Session Initiation 
Protocol, 1/155 17 FAY 112 172/9 Uen Rev. B And 

Re: [Sip-implementors] 400 BadRequest

[Paul Kyzivat]

On 2/22/21 9:09 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

Hi again !
Correction, there are of course not any "require: 100Rel" in INVITE, sorry I 
mixed things up !
BR/pj


We have a vendor that is saying that they correctly answers initial INVITE with 400 BadRequest 
because the INVITE have SIP header "supported: precondition" and also required: 
100rel", but not the equivalent QOS parameters in SDP.

Personally I think that this behavior is definitely against the "spirit" of 
SIP, but is it really in accordance with 3GPP 24.229  ?


I won't comment on 3gpp-specific aspects. But from a pure sip 
perspective I see nothing wrong with declaring supported:precondition 
but choosing not to negotiate any preconditions at that time. There is a 
distinction between support and use.


Based on your stated facts, and assuming there was nothing else wrong, 
IMO the UAS should have processed the incoming request.


If you post the full request then it should be possible to be more 
definitive about this. (The link you posted below doesn't work for me.)


Thanks,
Paul


"The MSC sends 400 Bad Request because the received SIP Invite has precondition 
in the header part but no precondition related attributes in the SDP part.

This behavior is according to Function Specification Session Initiation 
Protocol, 1/155 17 FAY 112 172/9 Uen Rev. B And 3GPP 24.229.
2.21.1.1.1   INVITE Received with SDP 
Offer
When MSC-S receives initial INVITE with SDP offer containing precondition related 
attributes within SDP body, it requires both precondition and 100rel to be present 
in Require or Supported header. MSC-S behavior is the same regardless if 
precondition tag is received in Require or Supported header. If any of the required 
option-tags is missing, INVITE is rejected wit 421 Extension Required and the 
missing option-tags within Require header. If the received SDP offer contains no 
precondition related attributes, but both precondition and 100relare present in 
Require or Supported header, INVITE is rejected with 400 Bad Request."


BR/pj



Sensitivity: Internal
___
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] reuse of payload type

[Paul Kyzivat]

audio 49120 RTP/AVP 109 104 110 102 108 105 100
  b=AS:50
  b=RS:625
  b=RR:1875
  a=rtpmap:109 EVS/16000
  a=fmtp:109 br=13.2-24.4; bw=nb-wb; max-red=0; cmr=-1; ch-aw-recv=-1
  a=rtpmap:104 AMR-WB/16000
  a=fmtp:104 max-red=220; mode-change-capability=2
  a=rtpmap:110 AMR-WB/16000
  a=fmtp:110 octet-align=1; max-red=220; mode-change-capability=2
  a=rtpmap:102 AMR/8000
  a=fmtp:102 max-red=220; mode-change-capability=2
  a=rtpmap:108 AMR/8000
  a=fmtp:108 octet-align=1; max-red=220; mode-change-capability=2
  a=rtpmap:105 telephone-event/16000
  a=fmtp:105 0-15
  a=rtpmap:100 telephone-event/8000
  a=fmtp:100 0-15
  a=ptime:20
  a=maxptime:20
  a=sendrecv


ACK with SDP as answer on offer from VoLTE-phone

   SDP PDU

  v=0

  o=- 805658488335263 1704590317 IN IP6 2A02:1400:10:1C::4

  s=-

  c=IN IP6 2a02:1400:10:1::4

  t=0 0

  m=audio 5394 RTP/AVP 104 105

  b=AS:54

  a=rtpmap:104 AMR-WB/16000

  a=fmtp:104 mode-set=0,1,2; mode-change-period=2; 
mode-change-capability=2; mode-change-neighbor=1; max-red=0

  a=rtpmap:105 telephone-event/16000

  a=ptime:20

  a=maxptime:40

BR/pj







-Original Message-
From: Paul Kyzivat mailto:pkyzi...@alum.mit.edu>>
Sent: den 22 januari 2021 16:31
To: Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>>; 
sip-implementors@lists.cs.columbia.edu<mailto:sip-implementors@lists.cs.columbia.edu>
Subject: Re: [Sip-implementors] reuse of payload type



On 1/22/21 7:55 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:



[snip]




As you can see the offer in initial INVITE have payload type 100:



a=rtpmap:100 AMR/8000 The offer in 200OK also have payload-type 100,



but now it is: a=rtpmap:100 telephone-event/8000







I believe that this is causing failure when B-side (VoLTE-phone) is



sending TelephoneEvent(DTMF) to A-side (UAC)







Do you think A-side should adapt or maybe reject the offer in 200OK or do 
something else ?











RFC3264  8.3.2



 "However, in the case of RTP, the mapping from a particular dynamic 
payload type



 number to a particular codec within that media stream MUST NOT change



 for the duration of a session.  For example, if A generates an offer



 with G.711 assigned to dynamic payload type number 46, payload type



 number 46 MUST refer to G.711 from that point forward in any offers



 or answers for that media stream within the session. "




I compared the two SDPs and find that there aren't *any* codec+fmtp sets that 
match. So this is messed up. But you haven't provided enough information to 
fully decipher what is going on. We need to see the answer to the first invite. 
The restrictions of rfc3264 section 8.3.2 pertain to the PT values used by a 
particular endpoint. (It is permissible to use different PTs on the two ends.) 
But in this case there isn't anything that could be in that first answer that 
could render this second answer valid.



Regarding whether the A-side should adapt or reject: this is an implementation 
decision. The specs don't specify behavior for non-conforming usage. Or course 
there is also the problem that you can't reject an answer. All you can do is 
try sending another offer, or else terminate the call.



It isn't entirely clear what you could try in order to carry on while accepting 
this 2nd answer. You could start sending using one or more of the codecs in the 
answer, but it is unclear what you would expect to receive.



  Thanks,

  Paul




Sensitivity: Internal
___
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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C76e15095ceb6408fb20008d8bef77998%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637469317390117199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t2bp3O3eGF1L8K2RQi138cQcQQtBiW80K5%2FsUI4CBqI%3D=0>


Sensitivity: Internal


___
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] reuse of payload type

[Paul Kyzivat]

On 1/22/21 7:55 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

[snip]


As you can see the offer in initial INVITE have payload type 100: a=rtpmap:100 
AMR/8000
The offer in 200OK also have payload-type 100, but now it is: a=rtpmap:100 
telephone-event/8000

I believe that this is causing failure when B-side (VoLTE-phone) is sending 
TelephoneEvent(DTMF) to A-side (UAC)

Do you think A-side should adapt or maybe reject the offer in 200OK or do 
something else ?


RFC3264  8.3.2
"However, in the case of RTP, the mapping from a particular dynamic payload 
type
number to a particular codec within that media stream MUST NOT change
for the duration of a session.  For example, if A generates an offer
with G.711 assigned to dynamic payload type number 46, payload type
number 46 MUST refer to G.711 from that point forward in any offers
or answers for that media stream within the session. "


I compared the two SDPs and find that there aren't *any* codec+fmtp sets 
that match. So this is messed up. But you haven't provided enough 
information to fully decipher what is going on. We need to see the 
answer to the first invite. The restrictions of rfc3264 section 8.3.2 
pertain to the PT values used by a particular endpoint. (It is 
permissible to use different PTs on the two ends.) But in this case 
there isn't anything that could be in that first answer that could 
render this second answer valid.


Regarding whether the A-side should adapt or reject: this is an 
implementation decision. The specs don't specify behavior for 
non-conforming usage. Or course there is also the problem that you can't 
reject an answer. All you can do is try sending another offer, or else 
terminate the call.


It isn't entirely clear what you could try in order to carry on while 
accepting this 2nd answer. You could start sending using one or more of 
the codecs in the answer, but it is unclear what you would expect to 
receive.


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 Colon (:) as Header delimiter of name-value

[Paul Kyzivat]

On 8/14/20 1:30 PM, Maxim Sobolev wrote:
I agree "doing nothing wrong" seems like a better verdict. :) Its 
implementors could have been more considerate of naive/ignorant 
implementations though.


Trying to anticipate and work around problems with other people's 
implementations is a futile game. You will never be able to anticipate 
all the stupid things people do. Given the syntax of the call-id header 
field, why is colon any more special than any other character allowed in 
"word". If you look at the comments in the abnf they explicitly say that 
they are trying to allow as much as possible.


Thanks,
Paul


-Max

On Fri., Aug. 14, 2020, 9:13 a.m. Paul Kyzivat, <mailto:pkyzi...@alum.mit.edu>> wrote:


On 8/14/20 10:25 AM, Maxim Sobolev wrote:
 > Paul, there is no space between colon and the rest of the call-id
in the
 > original example provided. So UAC seems to be doing the right
thing I think.
 >
 > Call-ID: :VaT4082403130oFbc
 >

<mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org

<mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>>...
 >

OK. If there is no space then I agree that the UAC is doing nothing
wrong.

         Thanks,
         Paul

 > -Max
 >
 >
 > On Thu., Aug. 13, 2020, 8:15 a.m. Paul Kyzivat,
mailto:pkyzi...@alum.mit.edu>
 > <mailto:pkyzi...@alum.mit.edu <mailto:pkyzi...@alum.mit.edu>>> wrote:
 >
 >     Pravin, Gaurav,
 >
 >     On 8/13/20 5:34 AM, Pravin Kumar wrote:
 >      > Hi Gaurav,
 >      >
 >      > You can refer to RFC3261 Call-ID ABNF syntax section:
 >      >
 >      > [RFC3261 - page 228]
 >      >
 >      > Call-ID  =  ( "Call-ID" / "i" ) HCOLON callid
 >      > callid   =  word [ "@" word ]
 >      >
 >      > [RFC3261 - page221]
 >      >
 >      >        word        =  1*(alphanum / "-" / "." / "!" / "%"
/ "*" /
 >      >                       "_" / "+" / "`" / "'" / "~" /
 >      >                       "(" / ")" / "<" / ">" /
 >      >                       ":" / "\" / DQUOTE /
 >      >                       "/" / "[" / "]" / "?" /
 >      >                       "{" / "}" )
 >      >
 >      > If you observe here ":" is allowed in call-id irrespective to
 >     position. So
 >      > in your case UAS behaviour is not correct to remove the
":". -pravin
 >
 >     I agree that colon is allowed in call-id, but whitespace is
not. So it
 >     appears to me that the UAC has erred.
 >
 >     Exactly what the UAS should do in this case is not defined. I
would
 >     suggest you either:
 >
 >     1) reject the request with a 400 response
 >     2) ignore the error and use the call-id as-is
 >
 >     The fact that your uas ignored the colon suggests to me that
its parser
 >     is acting in an unjustified way. (Ad hoc parsing?)
 >
 >              Thanks,
 >              Paul
 >
 >      > On Thu, Aug 13, 2020 at 2:30 PM Gaurav Khare
 >     mailto:gaurav.kh...@onmobile.com>
<mailto:gaurav.kh...@onmobile.com <mailto:gaurav.kh...@onmobile.com>>>
 >      > wrote:
 >      >
 >      >> Hi,
 >      >>
 >      >> I have a specific problem relating to SIP header format.
 >      >>
 >      >> A UAC is sending Call-ID Header in INVITE as below
 >      >> Call-ID: :
 >      >>
 >
vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org

<mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>
 >   
  <mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org <mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>>

 >      >>
 >      >> My UAS is sending 180 Ringing response as
 >      >> Call-ID:
 >      >>
 >
vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org

<mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>
 >   
  <mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org <

Re: [Sip-implementors] Multiple Colon (:) as Header delimiter of name-value

[Paul Kyzivat]

On 8/14/20 10:25 AM, Maxim Sobolev wrote:
Paul, there is no space between colon and the rest of the call-id in the 
original example provided. So UAC seems to be doing the right thing I think.


Call-ID: :VaT4082403130oFbc 
<mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>...




OK. If there is no space then I agree that the UAC is doing nothing wrong.

Thanks,
Paul


-Max


On Thu., Aug. 13, 2020, 8:15 a.m. Paul Kyzivat, <mailto:pkyzi...@alum.mit.edu>> wrote:


Pravin, Gaurav,

On 8/13/20 5:34 AM, Pravin Kumar wrote:
 > Hi Gaurav,
 >
 > You can refer to RFC3261 Call-ID ABNF syntax section:
 >
 > [RFC3261 - page 228]
 >
 > Call-ID  =  ( "Call-ID" / "i" ) HCOLON callid
 > callid   =  word [ "@" word ]
 >
 > [RFC3261 - page221]
 >
 >        word        =  1*(alphanum / "-" / "." / "!" / "%" / "*" /
 >                       "_" / "+" / "`" / "'" / "~" /
 >                       "(" / ")" / "<" / ">" /
 >                       ":" / "\" / DQUOTE /
 >                       "/" / "[" / "]" / "?" /
 >                       "{" / "}" )
 >
 > If you observe here ":" is allowed in call-id irrespective to
position. So
 > in your case UAS behaviour is not correct to remove the ":". -pravin

I agree that colon is allowed in call-id, but whitespace is not. So it
appears to me that the UAC has erred.

Exactly what the UAS should do in this case is not defined. I would
suggest you either:

1) reject the request with a 400 response
2) ignore the error and use the call-id as-is

The fact that your uas ignored the colon suggests to me that its parser
is acting in an unjustified way. (Ad hoc parsing?)

         Thanks,
         Paul

 > On Thu, Aug 13, 2020 at 2:30 PM Gaurav Khare
mailto:gaurav.kh...@onmobile.com>>
 > wrote:
 >
 >> Hi,
 >>
 >> I have a specific problem relating to SIP header format.
 >>
 >> A UAC is sending Call-ID Header in INVITE as below
 >> Call-ID: :
 >>
vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org

<mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>
 >>
 >> My UAS is sending 180 Ringing response as
 >> Call-ID:
 >>
vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org

<mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>
 >> >
vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org

<mailto:vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>>
 >>
 >> Notice the two colons in UAC request. In the response my stack
is ignoring
 >> additional Colon(:) but the response is rejected by UAC. I am
perplexed as
 >> to if colon(:) can be a part of Call-ID value or if two
Colons(:) can occur
 >> sequentially delimiting Header name and value.
 >>
 >> If someone can point me to a Section of RFC, it will be very
helpful.
 >>
 >> Thanks in advance,
 >> Gaurav Khare
 >>
 >>
 >>
 >> 
 >>
 >> DISCLAIMER: The information in this message is confidential and
may be
 >> legally privileged. It is intended solely for the addressee.
Access to this
 >> message by anyone else is unauthorized. If you are not the intended
 >> recipient, any disclosure, copying, or distribution of the
message, or any
 >> action or omission taken by you in reliance on it, is prohibited
and may be
 >> unlawful. Please immediately contact the sender if you have
received this
 >> message in error. Further, this e-mail may contain viruses and all
 >> reasonable precaution to minimize the risk arising there from is
taken by
 >> OnMobile. OnMobile is not liable for any damage sustained by you
as a
 >> result of any virus in this e-mail. All applicable virus checks
should be
 >> carried out by you before opening this e-mail or any attachment
thereto.
 >> Thank you - OnMobile Global Limited.
 >> ___
 >> 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] Multiple Colon (:) as Header delimiter of name-value

[Paul Kyzivat]

Pravin, Gaurav,

On 8/13/20 5:34 AM, Pravin Kumar wrote:

Hi Gaurav,

You can refer to RFC3261 Call-ID ABNF syntax section:

[RFC3261 - page 228]

Call-ID  =  ( "Call-ID" / "i" ) HCOLON callid
callid   =  word [ "@" word ]

[RFC3261 - page221]

   word=  1*(alphanum / "-" / "." / "!" / "%" / "*" /
  "_" / "+" / "`" / "'" / "~" /
  "(" / ")" / "<" / ">" /
  ":" / "\" / DQUOTE /
  "/" / "[" / "]" / "?" /
  "{" / "}" )

If you observe here ":" is allowed in call-id irrespective to position. So
in your case UAS behaviour is not correct to remove the ":". -pravin


I agree that colon is allowed in call-id, but whitespace is not. So it 
appears to me that the UAC has erred.


Exactly what the UAS should do in this case is not defined. I would 
suggest you either:


1) reject the request with a 400 response
2) ignore the error and use the call-id as-is

The fact that your uas ignored the colon suggests to me that its parser 
is acting in an unjustified way. (Ad hoc parsing?)


Thanks,
Paul


On Thu, Aug 13, 2020 at 2:30 PM Gaurav Khare 
wrote:


Hi,

I have a specific problem relating to SIP header format.

A UAC is sending Call-ID Header in INVITE as below
Call-ID: :
vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org

My UAS is sending 180 Ringing response as
Call-ID:
vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org


Notice the two colons in UAC request. In the response my stack is ignoring
additional Colon(:) but the response is rejected by UAC. I am perplexed as
to if colon(:) can be a part of Call-ID value or if two Colons(:) can occur
sequentially delimiting Header name and value.

If someone can point me to a Section of RFC, it will be very helpful.

Thanks in advance,
Gaurav Khare





DISCLAIMER: The information in this message is confidential and may be
legally privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, or distribution of the message, or any
action or omission taken by you in reliance on it, is prohibited and may be
unlawful. Please immediately contact the sender if you have received this
message in error. Further, this e-mail may contain viruses and all
reasonable precaution to minimize the risk arising there from is taken by
OnMobile. OnMobile is not liable for any damage sustained by you as a
result of any virus in this e-mail. All applicable virus checks should be
carried out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.
___
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 Session Refresh RFC 4028

[Paul Kyzivat]

On 8/6/20 8:39 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

Hi !
Details about refresher is missing in your description, but I believe that 
B2BUA should accept UAS(B) value !


I disagree with your conclusion.

While there is no explicit information about the refresher, the 
commentary implies that the B2BUA concludes that it should be the 
refresher. So I presume it was set so in the 200 response.


Also, Party-A is irrelevant to the question at hand. The B2BUA should be 
considered to be just a UA for the purposes of the analysis.


Party-B has done two things wrong:

1) It included Session-Expires and Supported:timer in the response, 
indicating that it does support timers, but (I guess) did not include 
Require:timer. There should never be a 200 response that has that 
combination of settings.


2) It has returned a value in Session-Expires that is less than the 
value of Min-SE in the request. This is also non-conforming behavior.


The RFC doesn't say what the UAC (B2BUA) should do in this case. The 
absence of Require:timer in the response means that no timer session has 
been established and so the B2BUA isn't obligated to send refreshes at 
any interval.


Party-B is of course entitled to send a BYE any time it likes. But it is 
wrong to blame the B2BUA for the failure of the call.


It is unreasonable to expect the B2BUA to act in this case by acting as 
refresher with interval 240. That is less than it has already indicated 
that it is willing to do.


Party-B needs to fix its implementation. If it really feels it needs a 
refresh interval of 240 then it can refuse to set up the call by 
returning an error immediately. Or, it can set up the call without 
session timer, and then send re-invites (or any other request) at the 
interval it desires to test the session.


Thanks,
Paul


As per RFC 4028, following is the behavior of UAS.
9.  UAS Behavior
The UAS response MAY reduce its value but MUST NOT set it to a
duration lower than the value in the Min-SE header field in the
request, if it is present; otherwise the UAS MAY reduce its value but
MUST NOT set it to a duration lower than 90 seconds.  The UAS MUST
NOT increase the value of the Session-Expires header field.

BR/pj


Sensitivity: Internal

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
 On Behalf Of Basu Chikkalli
Sent: den 6 augusti 2020 13:22
To: sip-implementors 
Subject: [Sip-implementors] SIP Session Refresh RFC 4028

Hi All,

A->B2BUA>B

A-Party does not support session.
   no Session_Expires,no Min-SE and no Supported:timer
   So no session refresh between A and B2BUA.

When B2BUA supports timer.
It sends INVITE to B with following details
B2BUA---INVITE-->B
Supported : timer
Session_Expires : 840
Min-SE : 360


B2BUA<<200-OK--B
Supported:timer
Session_Expires:240
Min-SE: 120

   The B2BUA not obeying B' session_expires and starts timer on 840 sec.
resulting B-Party sending BYE to the session after it's timer expiry.

Should B2BUA should start timer on B's session_expires value (240sec) or it's 
own session_expires (840)?

Thanks
Basu
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementorsdata=02%7C01%7Cper-johan.sundbaum%40telenor.se%7C5912c13c441e41452e0f08d839faed6b%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C1%7C637323097177046922sdata=aYNwmn%2Ba0zpNYY7JMtkODt1Zeg3SJHovwBB34yc6PjY%3Dreserved=0
___
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 SIM swap

[Paul Kyzivat]

Since this discussion seems to be specific to 3gpp use of SIP I suggest 
you continue this discussion in some 3gpp-specific forum.


On 5/11/20 7:50 PM, ankur bansal wrote:

Hi Ranjit

There is no clear specification saying UE should deregister when SIM is
removed .
But if refer multiple specs , we can reach a point where UE supposed to do
it .

As per 3gpp 24.301
5.5.2.1 General

*The detach procedure with appropriate detach type shall be invoked by the
UE* if the UE is switched off,
*the USIM cardis removed from the UE* or the EPS capability of the UE is
disabled or the UE wishes to detach for non-EPS services

As per FCM0.1 VoLTE Service Description and Implementation Guidelines

3.2.2 VoLTE UE Initiated Detach and IMS Deregistration
3.2.2.1 General
*A VoLTE UE shall automatically deregister from IMS before performing an
LTE Detach*


Even we have seen use-cases where there are services linked with SIM ,and
UE can do refresh registration removing those capabilities
when SIM is removed .

SIM swap anyway will be taken care if UE does IMS deregistration or
refresh-registration while SIM is removed.

Hope this helps.

Regards
Ankur Bansal


On Sun, May 3, 2020 at 8:37 PM Ranjit Avasarala 
wrote:


Thank you Dale.  as part of SIM swap testing, I came across the below
scenario:
the Phone number (MSISDN-1) was registered with IMSI (IMSI-1).  when SIM
Swap occurred, the INVITE came with a different IMSI and CSCF sends
diameter SAR with "Unregistered user". But HSS thinks user is registered
and sends SAA with DIAMETER_UNABLE_TO_COMPLY error.  CSCF translates this
error to 500 Internal Server Error.
So is this the expected behavior?

Regards
Ranjit

On Sun, May 3, 2020 at 9:07 PM Dale R. Worley  wrote:


Ranjit Avasarala  writes:

Does SIM swap procedure on a SIP UE trigger re-registration?  if not

when

calls are made from the device, the INVITE would have the IMSI of the

new

SIM card?


The answers aren't set by the SIP standards.  However, given that the
SIM gives the Directory Number of a PSTN telephone, I would expect that

if

you change the SIM on a UE, the UE would register for the new DN.

In SIP, the From address in an INVITE is not necessarily connected with
any AOR that the UE registers for.  But in a PSTN telephone, I would
expect it to use the SIM's DN as the From URI.

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



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

Re: [Sip-implementors] Usage of "User-Agent" in SIP responses

[Paul Kyzivat]

On 4/28/20 1:08 PM, Maxim Sobolev wrote:

Hi,

I've noticed that in the last few years few implementations have gained
popularity who use User-Agent in both requests and responses. Instead of
User-Agent in requests and Server in responses which I always believed
(perhaps incorrectly) to be the right way of doing it. The argument there
is that "oh, our implementation is an endpont/B2BUA, not an UAS".  The
question hence is it my reading of RFC wrong or theirs? Thanks!


From 3261:

   The Server header field contains information about the software used
   by the UAS to handle the request.
   ...
   The User-Agent header field contains information about the UAC
   originating the request.

And note that UAC and UAS are *roles*. If you initiating (not 
forwarding) a SIP request then you are, at that moment, acting as a UAC. 
And if you are initiating (not forwarding) a SIP response then you are 
acting as a UAS. In practice it is really hard (probably impossible) to 
find anything that is purely a UAC or UAS.


So the usage you are seeing is *wrong*.

This gets hazy with B2BUAs. Note that they have no official standing in 
3261. As far as 3261 is concerned  something that thinks of itself as a 
B2BUA is just two sip devices lashed together. When the B2BUA receives a 
request on one side it is acting as a UAS and when it sends it out the 
other side it is acting as a UAC. In principle that should be governing 
its use of User-Agent and Server on each side. But often they try to act 
as a Proxy. (Except when doing something that a Proxy isn't permitted to 
do.) I think they hand wave around this by claiming that they are 
sometimes acting as Proxies and other times are acting as UAs and so 
pick whichever suits them when arguing that they are compliant.


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

Re: [Sip-implementors] Proxy handling of in dialogue request

[Paul Kyzivat]

Jason,

On 3/20/20 1:22 PM, Alex Balashov wrote:

The proxy will send the request onward to the next Route hop. If no further 
Route hops are available, it will consume the domain portion of the Request URI 
and send the request to that.


For the complete story, *carefully* read section 16 of RFC3261. There is 
a lot there, some of it subtle, and all of it important.


Good Luck,
Paul


Sent from mobile, with due apologies for brevity and errors.


On Mar 20, 2020, at 9:23 AM, Jason Harrison  wrote:

Hi,

I know that a UA uses the remote target and route set to build the Route 
headers and request URI. What I cannot find detail on is how a stateful proxy 
will determine where to route the request.

Does the proxy have a remote target and route set like a UA, or does it simply 
use the request URI. I ask as I have a proxy server that does not route a BYE 
request and I am trying to understand why

Many 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] requirement to play media stream while on hold?

[Paul Kyzivat]

On 2/19/20 10:01 PM, Dale R. Worley wrote:

Paul Heitkemper  writes:

If you are placed on hold (a=sendonly), and the holder sends you a
media stream, are you required to play it? I looked through RFC's
3261, 2327, and 3264, but I don't really see a requirement to actually
play a media stream ever- when on hold or not.


That's right.  Indeed, there is essentially no specification of how a
SIP endpoint connects the RTP media streams to the user interface.  But
it might be difficult to sell a phone that will not render
media-on-hold.


It would probably be a poor phone implementation that unconditionally 
failed to play media on hold. But one that gives the user a way to 
locally mute it until two way media is reestablished could be a nice 
feature.


And a feature that allows you totally disconnect the call from the local 
media and black-hole it rather that hanging up could also be a nice feature.


This is all outside the scope of the SIP specifications.

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

Re: [Sip-implementors] SDP version

[Paul Kyzivat]

You can find the definitive statement you are looking for in Section 8 
of RFC3264:


   ... When issuing an offer that modifies the session,
   the "o=" line of the new SDP MUST be identical to that in the
   previous SDP, except that the version in the origin field MUST
   increment by one from the previous SDP.  If the version in the origin
   line does not increment, the SDP MUST be identical to the SDP with
   that version number. ...

Now you have a MUST you can point to.

(Nevertheless, in any code that I write I would never trust this!)

Good luck,
Paul


On 1/22/20 11:09 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

Hi !

I'm in IMS operations and sometimes I get stuck in the crossfire between 
different vendors !

The two SDP's are identical except the version-number, I have checked.
For the moment it seems that most of our nodes are accepting that version is 
incremented without session has changed in any other way, but
we have a vendor that are claiming that it's a violation of RFC 4028 - Session 
Timer and also claims that that violation is causing problems, so far
a bit unclear why and what, could be some kind of misunderstanding, but I have 
also colleagues that are arguing  that RFC 4028 is only valid for UA
with support for timer.

I think your view on the matter makes very good sense !

Thanks !

BR/pj


Sensitivity: Internal

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
 On Behalf Of Paul Kyzivat
Sent: den 22 januari 2020 16:25
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP version

Sorry, but I'm too lazy to compare those two messages byte by byte to see if 
they are identical other than the version number.

I don't understand the point of your question. Are you looking for an excuse to 
increment the version number without checking if the SDP has changed?

There is a fine line here between what is required behavior, what is good 
practice, what is considerate, ...

It really is a savings for the recipient of the SDP if he can avoid parsing it. And 
generally it should be easier for the sender to "know"
that the SDP is unchanged and so indicate that when sending it. It is a bit 
harder for the recipient to determine that. OTOH, as an implementor I'm not 
very trusting and so am inclined to not trust that it is unchanged without 
checking. Even so there are ways to take advantage of that indication without 
trusting it. (If the version # is the same as prior then do a string comparison 
of the two SDPs to verify. If the version #s are different, then simply start 
parsing the SDP without bothering with the comparison.)

And we shouldn't second guess what optimizations a peer may or may not want to 
do.

I guess the worst case is a situation where you would normally generate the SDP 
from scratch for every message and so not have an easy way to tell if it has 
changed. Then it becomes a question of whether you do the extra work to 
determine changed or not, or force extra work on the recipient. I think you 
should do it.

The session timer connection is, IMO, a red herring. That draft is poorly 
written, in that it seems to imply that an invite for session timer is mutually 
exclusive with one for offer/answer. The two processes share messages and can 
coexist or not.

Thanks,
Paul

On 1/22/20 6:50 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

Sorry for the no good picture !

SDP in 200OK for initial INVITE from PBX SDP PDU
v=0
o=- 195986 1 IN IP4 10.81.253.92
s=RFC3264OfferAnswerExchange
c=IN IP4 10.81.253.92
b=CT:1000
t=0 0
m=audio 23812 RTP/AVP 8 110
c=IN IP4 10.81.253.92
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=ptime:20


SDP in re-INVITE  from PBX
SDP PDU
v=0
o=- 195986 2 IN IP4 10.81.253.92
s=RFC3264OfferAnswerExchange
c=IN IP4 10.81.253.92
b=CT:1000
t=0 0
m=audio 23812 RTP/AVP 8 110
c=IN IP4 10.81.253.92
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=ptime:20

BR/pj

From: Rohit Jain 
Sent: den 22 januari 2020 12:36
To: Sundbaum Per-Johan (Telenor Sverige AB)

Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP version

Hi,

SIP entities (client/server) checks SDP version to determine whether there is 
any change in SDP from previously received SDP. If the version is changed then 
they go on to parse the entire SDP to determine the change.
Based on that SIP entity can initiate media processing(more relevant in case of 
servers) or just relay the message without any media level processing. If  just 
the version number is incremented but there is no actual change in SDP, then it 
will trigger unnecessary processing on the receiver, so it should be avoided.

Also can you specify what could be the requirement ("but is that true also for UA 
without support for timer") in which it is required to increment the SDP version 
number wi

Re: [Sip-implementors] SDP version

[Paul Kyzivat]

Sorry, but I'm too lazy to compare those two messages byte by byte to 
see if they are identical other than the version number.


I don't understand the point of your question. Are you looking for an 
excuse to increment the version number without checking if the SDP has 
changed?


There is a fine line here between what is required behavior, what is 
good practice, what is considerate, ...


It really is a savings for the recipient of the SDP if he can avoid 
parsing it. And generally it should be easier for the sender to "know" 
that the SDP is unchanged and so indicate that when sending it. It is a 
bit harder for the recipient to determine that. OTOH, as an implementor 
I'm not very trusting and so am inclined to not trust that it is 
unchanged without checking. Even so there are ways to take advantage of 
that indication without trusting it. (If the version # is the same as 
prior then do a string comparison of the two SDPs to verify. If the 
version #s are different, then simply start parsing the SDP without 
bothering with the comparison.)


And we shouldn't second guess what optimizations a peer may or may not 
want to do.


I guess the worst case is a situation where you would normally generate 
the SDP from scratch for every message and so not have an easy way to 
tell if it has changed. Then it becomes a question of whether you do the 
extra work to determine changed or not, or force extra work on the 
recipient. I think you should do it.


The session timer connection is, IMO, a red herring. That draft is 
poorly written, in that it seems to imply that an invite for session 
timer is mutually exclusive with one for offer/answer. The two processes 
share messages and can coexist or not.


Thanks,
Paul

On 1/22/20 6:50 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

Sorry for the no good picture !

SDP in 200OK for initial INVITE from PBX
SDP PDU
v=0
o=- 195986 1 IN IP4 10.81.253.92
s=RFC3264OfferAnswerExchange
c=IN IP4 10.81.253.92
b=CT:1000
t=0 0
m=audio 23812 RTP/AVP 8 110
c=IN IP4 10.81.253.92
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=ptime:20


SDP in re-INVITE  from PBX
SDP PDU
v=0
o=- 195986 2 IN IP4 10.81.253.92
s=RFC3264OfferAnswerExchange
c=IN IP4 10.81.253.92
b=CT:1000
t=0 0
m=audio 23812 RTP/AVP 8 110
c=IN IP4 10.81.253.92
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=ptime:20

BR/pj

From: Rohit Jain 
Sent: den 22 januari 2020 12:36
To: Sundbaum Per-Johan (Telenor Sverige AB) 
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP version

Hi,

SIP entities (client/server) checks SDP version to determine whether there is 
any change in SDP from previously received SDP. If the version is changed then 
they go on to parse the entire SDP to determine the change.
Based on that SIP entity can initiate media processing(more relevant in case of 
servers) or just relay the message without any media level processing. If  just 
the version number is incremented but there is no actual change in SDP, then it 
will trigger unnecessary processing on the receiver, so it should be avoided.

Also can you specify what could be the requirement ("but is that true also for UA 
without support for timer") in which it is required to increment the SDP version 
number without any actual change in SDP.
PS: Not able to get the attached picture.

Regards,
Rohit J

On Wed, Jan 22, 2020 at 4:31 PM Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>> wrote:
Hi !
What do you think about incrementing the version in SDP o-line, but not 
changing anything else in SDP,
should such a behavior be accepted or should it be rejected ?

RFC 4028 states that such behavior at least should be avoided, but is that true 
also for UA without support for timer ?

" RFC 4028 - Session Timer
  In that case, the offer MUST indicate
that it has not changed.  In the case of SDP, this is accomplished by
including the same value for the origin field as did previous SDP
messages to its peer.  The same is true for an answer exchanged as a
result of a session refresh request; if it has not changed, that MUST
be indicated. "

An example from reality in picture below, should it be accepted ?
I think it should be accepted.

[cid:image001.png@01D5D11B.59A78290]

BR/pj



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


--
Regards,
Rohit Jain


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



___
Sip-implementors mailing list

Re: [Sip-implementors] Query on SIP 488 response

[Paul Kyzivat]

On 12/15/19 12:31 AM, Ranjit Avasarala wrote:

Hi
I have a scenario where the terminating device responds with SIP 488 Not
Acceptable here response.  It is understood that the terminating device
does not support any of the codecs that the incoming INVITE has.

this issue occurred when a landline called VoLTE device and the
intermediate MSC/MGCF translated the SS7 message to SIP INVITE and put the
codecs it supports.  So since the terminating device does not support any
of the listed codecs in SIP INVITE SDP offer, it responded with 488 response

So my query is - is there a way the terminating device could indicate the
list of codecs it supports in 488 response?


RFC3261:

21.4.26 488 Not Acceptable Here

   The response has the same meaning as 606 (Not Acceptable), but only
   applies to the specific resource addressed by the Request-URI and the
   request may succeed elsewhere.

   A message body containing a description of media capabilities MAY be
   present in the response, which is formatted according to the Accept
   header field in the INVITE (or application/sdp if not present), the
   same as a message body in a 200 (OK) response to an OPTIONS request.

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

Re: [Sip-implementors] Proposal for a mew SIP 4xx Error code

[Paul Kyzivat]

Ranjit,

I see you cross posted this proposal to multiple lists. There is large 
overlap in readership of those lists, so this creates a mess. I'm going 
to reply here, because this is the best place for such a query.


Please see inline below.

On 10/29/19 12:05 AM, Ranjit Avasarala wrote:

Hello all

Many times I experienced scenarios where SIP requests (e.g. INVITE, PUBLISH
or PRACK or any other) have either invalid parameters in the header or a
particular header is missing in the request or the header value is
incomplete.  Some e.gs are

- SIP Route header in INVITE contains additional "lr" parameter.
Ideally, "lr" parameter needs to be associated with a particular route -
i.e. sip URI
- the Accept header is missing in SIP PUBLISH
- the Allow header misses UPDATE method
- .  many more

Currently, in all the above cases the SIP Proxy server that receives the
request, responds with a 400 Bad Request.
Though 400 Bad Request is acceptable given that there is some issue in the
SIP request, a more detailed error would be more useful - as sometimes
interpreting 400 Bad Request is harder


You can use the Reason-Phrase in the 400 response to clarify what you 
are complaining about. This should be sufficient to help a developer to 
diagnose the issue and fix it. It won't be sufficient to all a 
preprogrammed reaction in the UAC, but I don't see that as a reasonable 
expectation for problems like this.


Thanks,
Paul


E.g.
a  4xx Invalid header/parameter may be more appropriate with reason
E.g. if there is additional "lr" parameter in SIP INVITE, then the proxy
can return a 4xx Invalid Header/parameter with Reason:  SIP code=4xx;
Text="Invalid lr parameter in Route header"

Let me know your thoughts on if this proposal can be taken forward as an
Internet draft.

Thank you
Ranjit
___
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: ue-addr parameter in SIP Contact header

[Paul Kyzivat]

Ranjit,

Based on the further detail you provide below I conclude that this is 
most likely a question about 3GPP IMS behavior and specifications. I 
suggest that you take this to a 3GPP forum. (I don't know what that 
would be. Hopefully one of the people here who are involved in 3GPP can 
make say more.)


Thanks,
Paul

On 10/6/19 11:42 PM, Ranjit Avasarala wrote:

Hi Philip

Yes, I agree that connection and relation to UE are maintained by P-CSCF 
and S-CSCF does not need them.  But in some call scenarios, the S-CSCF 
connects to subsequent network elements like MRF and it is supposed to 
pass the "ue-addr" parameter it receives from P-CSCF (in Contact header) 
as is - without removing it


E.g.  there are 2 scenarios

Scenario-1:  INVITE from Access-SBC to S-CSCF with ue-addr: Contact: 
*;+g.3gpp.icsi*-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;mobility="fixed"


Scenario-2:  INVITE from Interconnect SBC to S-CSCF with ue-addr: 
Contact: 
*;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting*

*
*
In case of Scenario-1:  the S-CSCF is passing the ue-addr in Contact as 
is towards next hop but in Scenario-2, the S-CSCF is removing the 
ue-addr before passing the INVITE to next hop


Question:  why is S-CSCF removing ue-addr parameter in Scenario-2 and 
not removing in Scenario-1?  Does the position of ue-addr parameter in 
Contact header matter?


On Sun, Oct 6, 2019 at 12:00 PM Philipp Schöning > wrote:


Hi Ranjit,

I can't answer the question, but I have another question:
Isn't the connection and relation to the UE maintained by the P-CSCF?

 >From my perspective the S-CSCF does not have any relation to the UE.

BR
Philipp
___
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] session refresh

[Paul Kyzivat]

On 9/24/19 6:03 AM, Philipp Schöning wrote:

This was most likely a typo, RFC 3264 describes SDP offer/answer model.


Yes, it was a typo. Sorry.


Am Di., 24. Sept. 2019 um 07:40 Uhr schrieb Sundbaum Per-Johan (Telenor
Sverige AB) :


Thank you, really helpful, but I need help on what I should look for in
RFC3265,  I can't find that there is any mention of SDP's in it ?
BR/pj


___
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] session refresh

[Paul Kyzivat]

On 9/23/19 5:00 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

Hi !
Can anybody help me find relevant RFC/other info on how UAS should handle 
re-INVITE that is intended as a session refresh and not for modifying the 
session ?


A pure session refresh is something that can only be recognized in 
retrospect, not in advance.


Since that is the caller's desire, he is off to a good start by offering 
B1 again in (5). That indicates doesn't want to change anything. But 
there is no guarantee that the caller will want to keep things as they 
are. (Though the probability is high.)


In this case the caller MAY send A1 in (6), and that would make clear 
that it too prefers a "pure" session request.


OTOH, the caller MAY send any SDP in (6) that complies with O/A rules as 
specified in RFC3265.


I suggest you review RFC6337, notably section 5. It also cross 
references parts of other RFCs that motivate what it says.


Thanks,
Paul


SDP B1 in (3) is identical with SDP B1 in (5)



  CallerCallee
| |
| |
   |(1) INVITE with SDP A1   |
|>|
| |
| |
|(2)  Trying  |
|<|
| |
| |
|(3) 200 OK with SDP B1   | |
|<|
| |
| |
|(4) ACK  |
|>|
| |
| |
|(5) (re)INVITE with SDP B1   |
|<|
| |
| |
|(6) 200 OK with SDP  |
|>|


Thanks !
BR/pj



Sensitivity: Internal
___
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 fallback to media after Fax

[Paul Kyzivat]

On 9/20/19 12:49 AM, Rohit Jain wrote:

Hi All,

I have a query that can a SIP device fallback from fax to audio  again.
Following is the scenario:

User initiated a call with audio and call is connected.
After this user sent a ReInvite with t38 fax and both offer answer are
negotiated.

Can a user again send ReInvite with audio, or after fax call should be
disconnected.

In Normal scenario to send Fax, first audio is required to be established
in SIP. Once fax is done can endpoint again fallback to audio ? Is it a
practical usecase ?


This isn't really a sip question. From a sip signaling perspective it is 
totally fine to change media over and over again within a call. So if 
you want to revert from t38 back to normal audio then go ahead and make 
an offer to do so.


It question is whether the other end is prepared to handle the change. 
That will depend upon its construction. If not, then presumably it will 
refuse the offer to change and/or terminate the call. If your request to 
change back fails, but the call remains up, then you can make a new 
decision about what you want 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] renegotiate rtp <--> srtp in mid call

[Paul Kyzivat]

On 9/10/19 9:14 AM, J C Sunil Kumar Reddy wrote:

Hi All,
Can we renegotiate a rtp call to srtp and vice-versa in midcall? May be
with re-INVITE or UPDATE message? Is it a valid scenario if srtp is not
mandated?

In my scenario, server and client both supports RTP and SRTP and initially
call is negotiated to srtp call. Midway, server is sending a re-INVITE
asking to change to RTP.  What should client do in this case? Accept, as
SRTP is not mandatory or drop the call?

Which RFC should I refer for this scenario and what does it say in this
case?


I don't know of any document that discusses this exact scenario. But 
this is simply a particular case of replacing one medium with another, 
and so it entirely appropriate.


While you should be able to just change the existing m= line, you might 
want to consider just disabling that one with port=0 and adding a 
different m= line for the srtp.


Or you could use one O/A exchange to disable the old media with port=0 
and then use yet another O/A to re-establish it with srtp and a valid port.


But "just changing it" ought to work.

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-TAG(Local Tag) Need - Detailed Explained Req

[Paul Kyzivat]

Sridhar,

Please do not try to learn SIP from RFC2543.

RFC3261 replaced and obsoleted RFC2543 long ago. It is authoritative, 
but do please note that it has been extended and revised many times. 
(See the "Updated by" list at the top of 
https://tools.ietf.org/html/rfc3261.)


If you are just getting started then you will benefit greatly by reading 
a tutorial book such as:


SIP - Understanding the Session Initiation Protocol
https://www.amazon.com/SIP-Understanding-Session-Initiation-Protocol/dp/1608078639/ref=sr_1_1?keywords=understanding+the+session+initiation+protocol=1567523861=gateway=8-1

Good Luck,
Paul

On 9/3/19 6:58 AM, Sridhar Kumar N wrote:

Dear All

Good Day,

While Studying SIP protocal, Stuck at FROM-TAG usage.
TO-TAG usage is clearly explained in RFC2543. But FROM -TAG usage is
written in 2lines.
Can you please elaborate for understanding.


If the From address can appear
in requests generated by other user agent clients for the same call,
the caller MUST insert the tag parameter in the From field.




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

Re: [Sip-implementors] NOTIFY and Record-Route

[Paul Kyzivat]

On 7/25/19 5:53 AM, David Cunningham wrote:

Though I notice that RFC 6665 4.4.1 also says:

     unless the NOTIFY request contains a "Subscription-State" of 
"terminated."


And in our case the subscription state is "terminated". The dialog is 
then over, so I guess that the other RFCs then apply.


Hmm. I forgot that 6665 did some funky things to this process. It is an 
update to rfc3265 and was intended to resolve some problems that cropped 
up with 3265. Moving the establishment of the route set to the notify 
means that you don't have one between the receipt of the 2xx and the 
NOTIFY. One of the reasons for this is that the NOTIFY might have been 
forked, but only one 2xx response can be returned, but every fork could 
send a NOTIFY, each establishing a separate dialog. This means that the 
Record-Route in the first NOTIFY (if non-"terminated") needs to be the 
same as sent in the 2xx of the SUBSCRIBE. Meanwhile that is also used as 
the Route put into the NOTIFY by the notifier.


What I told you is correct for non-SUBSCRIBE dialogs (IOW, INVITE 
dialogs). Any servers on the path that would normally update the 
Record-Route in the 2xx response to the SUBSCRIBE will also need to make 
those same changes to the Record-Route in the NOTIFY.


The "terminated" does mean the dialog is ended (or was never 
established), so your subsequent SUBSCRIBE should start over with a new 
from-tag and no to-tag.


Sorry for forgetting about 6665.

Thanks,
Paul

On Thu, 25 Jul 2019 at 21:43, David Cunningham 
mailto:dcunning...@voisonics.com>> wrote:

 >
 > Thank you Paul, and thank you Richard.
 >
 > I must say RFC 6665 4.4.1 does seem to make it clear that the route 
set in the NOTIFY should be used, and therefore it's incorrect that the 
re-SUBSCRIBE sends directly to the Contact address rather than using the 
Record-Routes in the NOTIFY. It's very helpful to have this knowledge as 
a reference!

 >
 >
 > On Thu, 25 Jul 2019 at 00:01, Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:

 >>
 >> On 7/23/19 7:38 PM, David Cunningham wrote:
 >> > Hi Paul,
 >> >
 >> > I'd just like to check my understanding of your reply. The first
 >> > SUBSCRIBE is from the UAC sip:113...@es8.example.com 
<mailto:sip%3a113...@es8.example.com>
 >> > <mailto:sip%3a113...@es8.example.com 
<mailto:sip%253a113...@es8.example.com>>, and gets a 200 OK reply from

 >> > the UAS. It is the 200 OK that should contain the Record-Route header?
 >>
 >> The normal process is that as the *request* is forwarded from the UAC
 >> through proxies and on to the UAS, each proxy along the way has the
 >> opportunity to add itself to the Record-Route header (or add the header
 >> if one isn't already there). When it reaches the UAS, it should then
 >> copy the Record-Route into response - both provisional and 2xx. This
 >> then normally flows unchanged through all the proxies back to the UAC.
 >>
 >> The contents of the Record-Route then become the "route set" at both the
 >> UAC and UAS, together with the Contact URL from the other end.
 >>
 >> (The above it typical. In exotic cases the UAC and/or the UAS may also
 >> add one or more entries on the R-R, and entries might be added or
 >> changed on the R-R in response as it returns. But these are unusual.)
 >>
 >> > And would that then oblige the UAC to use that route on all future
 >> > transactions, even if the UAS sends a request (in this case a notify)
 >> > which changes it's Contact address?
 >>
 >> The route-set remains unchanged for the duration of the dialog, but the
 >> Contact address of the other end can change.
 >>
 >> > If you happen know which part of the RFC specifies this would be 
be good

 >> > to know. Thank you again for your help on this.
 >>
 >> This is all in 3261, but scattered around. Just search for Record-Route
 >> and "route set".
 >>
 >> There are other mechanisms that might be of interest to you. Check out
 >> the Path [RFC3327] and Service-Route [RFC3608] header fields. These
 >> affect the Route used for *out of dialog* requests. If those requests
 >> establish a dialog then Record-Route is still used to establish the
 >> route set for subsequent in-dialog requests.
 >>
 >>         Thanks,
 >>         Paul
 >>
 >> > On Tue, 23 Jul 2019 at 13:03, Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>

 >> > <mailto:pkyzi...@alum.mit.edu <mailto:pkyzi...@alum.mit.edu>>> wrote:
 >> >
 >> >     On 7/22/19 7:09 PM, David Cunningham wrote:
 >> >      > Hi Paul

Re: [Sip-implementors] NOTIFY and Record-Route

[Paul Kyzivat]

On 7/23/19 7:38 PM, David Cunningham wrote:

Hi Paul,

I'd just like to check my understanding of your reply. The first 
SUBSCRIBE is from the UAC sip:113...@es8.example.com 
<mailto:sip%3a113...@es8.example.com>, and gets a 200 OK reply from 
the UAS. It is the 200 OK that should contain the Record-Route header?


The normal process is that as the *request* is forwarded from the UAC 
through proxies and on to the UAS, each proxy along the way has the 
opportunity to add itself to the Record-Route header (or add the header 
if one isn't already there). When it reaches the UAS, it should then 
copy the Record-Route into response - both provisional and 2xx. This 
then normally flows unchanged through all the proxies back to the UAC.


The contents of the Record-Route then become the "route set" at both the 
UAC and UAS, together with the Contact URL from the other end.


(The above it typical. In exotic cases the UAC and/or the UAS may also 
add one or more entries on the R-R, and entries might be added or 
changed on the R-R in response as it returns. But these are unusual.)


And would that then oblige the UAC to use that route on all future 
transactions, even if the UAS sends a request (in this case a notify) 
which changes it's Contact address?


The route-set remains unchanged for the duration of the dialog, but the 
Contact address of the other end can change.


If you happen know which part of the RFC specifies this would be be good 
to know. Thank you again for your help on this.


This is all in 3261, but scattered around. Just search for Record-Route 
and "route set".


There are other mechanisms that might be of interest to you. Check out 
the Path [RFC3327] and Service-Route [RFC3608] header fields. These 
affect the Route used for *out of dialog* requests. If those requests 
establish a dialog then Record-Route is still used to establish the 
route set for subsequent in-dialog requests.


Thanks,
Paul

On Tue, 23 Jul 2019 at 13:03, Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:


On 7/22/19 7:09 PM, David Cunningham wrote:
 > Hi Paul,
 >
 > Thank you for the reply. Below is the full exchange, which hopefully
 > makes things clearer.

Yes it does.

 > Ultimately the problem is the SUBSCRIBE at the end
 > which is being sent to port 53426 - is it correct because it's
going to
 > the Contact address in the NOTIFY, or is it incorrect because
it's not
 > following the Record-Route?

To the best of my understanding it is correct.

To get the effect you seem to be going for, the proxy at
sip:yy.yy.yy.146:5061 should add a Record-Route with its own URL to the
first SUBSCRIBE. Then the UA mailto:sip%3a113...@es8.example.com>> will add
it to the reSUBSCRIBE as a Route header.

         Thanks,
         Paul

 > SUBSCRIBE sip:7...@es8.example.com:5061
<http://sip:7...@es8.example.com:5061>
 > <http://sip:7...@es8.example.com:5061> SIP/2.0
 > Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
 > Route: 
 > From: ES8 Test 104 mailto:sip%3a113...@es8.example.com>
 > <mailto:sip%3a113...@es8.example.com

<mailto:sip%253a113...@es8.example.com>>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
 > To: "798" http://sip:7...@es8.example.com:5061>
 > <http://sip:7...@es8.example.com:5061>>
 > Call-ID: 1552952...@xx.xx.xx.10
 > CSeq: 876 SUBSCRIBE
 > Contact: 
 > Supported: eventlist, 100rel
 > Proxy-Authorization: Digest username="113368",
 > realm="es8.example.com <http://es8.example.com>
<http://es8.example.com>",
 > nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp",
uri="sip:798@192.168.3.1 <mailto:sip%3A798@192.168.3.1>
 > <mailto:sip%3A798@192.168.3.1 <mailto:sip%253A798@192.168.3.1>>",
 > response="a480f0356c0654435c742114dfe8c4da", algorithm=MD5
 > Max-Forwards: 70
 > User-Agent: ewb2bua/15.4.3Alpha.2019053
 > Event: dialog
 > Expires: 300
 > Allow: UPDATE, REFER
 > Accept: application/dialog-info+xml
 > Content-Length: 0
 >
 >
 > SIP/2.0 200 OK
 > To: "798" http://sip:7...@es8.example.com:5061>
 > <http://sip:7...@es8.example.com:5061>>;tag=155960081226925
 > From: ES8 Test 104 mailto:sip%3a113...@es8.example.com>
 > <mailto:sip%3a113...@es8.example.com

<mailto:sip%253a113...@es8.example.com>>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
 > Via: SIP/2.0/TLS
xx.xx.xx.10:5061;rport=53426;branch=z9hG4bK1954587875
 > Call-ID: 1552952...@xx.xx.xx.10
 > CSeq: 876 SUBSCRIBE
 > Expires: 

Re: [Sip-implementors] NOTIFY and Record-Route

[Paul Kyzivat]

On 7/22/19 7:09 PM, David Cunningham wrote:

Hi Paul,

Thank you for the reply. Below is the full exchange, which hopefully 
makes things clearer.


Yes it does.

Ultimately the problem is the SUBSCRIBE at the end 
which is being sent to port 53426 - is it correct because it's going to 
the Contact address in the NOTIFY, or is it incorrect because it's not 
following the Record-Route?


To the best of my understanding it is correct.

To get the effect you seem to be going for, the proxy at 
sip:yy.yy.yy.146:5061 should add a Record-Route with its own URL to the 
first SUBSCRIBE. Then the UA  will add 
it to the reSUBSCRIBE as a Route header.


Thanks,
Paul

SUBSCRIBE sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061> SIP/2.0

Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1954587875
Route: 
From: ES8 Test 104 <mailto:sip%3a113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" <http://sip:7...@es8.example.com:5061>>

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 876 SUBSCRIBE
Contact: 
Supported: eventlist, 100rel
Proxy-Authorization: Digest username="113368", 
realm="es8.example.com <http://es8.example.com>", 
nonce="XPWf2Fz1nqyIJkgVG+Nm6jXXume5Pekp", uri="sip:798@192.168.3.1 
<mailto:sip%3A798@192.168.3.1>", 
response="a480f0356c0654435c742114dfe8c4da", algorithm=MD5

Max-Forwards: 70
User-Agent: ewb2bua/15.4.3Alpha.2019053
Event: dialog
Expires: 300
Allow: UPDATE, REFER
Accept: application/dialog-info+xml
Content-Length: 0


SIP/2.0 200 OK
To: "798" <http://sip:7...@es8.example.com:5061>>;tag=155960081226925
From: ES8 Test 104 <mailto:sip%3a113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Via: SIP/2.0/TLS xx.xx.xx.10:5061;rport=53426;branch=z9hG4bK1954587875
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 876 SUBSCRIBE
Expires: 300
Contact: <http://sip:7...@es8.example.com:5061>>

User-Agent: Example SIP server
Content-Length: 0


NOTIFY sip:113...@xx.xx.xx.10:53426;transport=tls SIP/2.0
Max-Forwards: 10
Record-Route: 
Record-Route: 
Via: SIP/2.0/TLS 
yy.yy.yy.146:5061;branch=z9hG4bK4b91.0cf32b66d634969dec31117b9c120464.0
Via: SIP/2.0/UDP 
127.0.0.1;rport=56095;received=yy.yy.yy.146;branch=z9hG4bKCkq6GHVlo4
From: <http://sip:7...@es8.example.com:5061>>;tag=155960081226925
To: <mailto:sip%3a113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Contact: 
Call-ID: 1552952...@xx.xx.xx.10
CSeq: 901 NOTIFY
User-Agent: Example presence server
Event: dialog
Subscription-State: active;expires=299
Content-Type: application/dialog-info+xml
Content-Length: 271


state="full" entity="sip:7...@es8.example.com:5061 
<http://sip:7...@es8.example.com:5061>">


terminated




SIP/2.0 200 OK
Via: SIP/2.0/TLS 
yy.yy.yy.146:5061;branch=z9hG4bK4b91.0cf32b66d634969dec31117b9c120464.0
Via: SIP/2.0/UDP 
127.0.0.1;rport=56095;received=yy.yy.yy.146;branch=z9hG4bKCkq6GHVlo4

Record-Route: 
Record-Route: 
From: <http://sip:7...@es8.example.com:5061>>;tag=155960081226925
To: <mailto:sip%3a113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 901 NOTIFY
Content-Length: 0


SUBSCRIBE sip:7...@yy.yy.yy.146:56095 SIP/2.0
Via: SIP/2.0/TLS xx.xx.xx.10:5061;branch=z9hG4bK1045495431
From: ES8 Test 104 <mailto:sip%3a113...@es8.example.com>>;tag=Nf5GGb2cl6tUMcx2B18758F8644a2998
To: "798" <http://sip:7...@es8.example.com:5061>>;tag=155960081226925

Call-ID: 1552952...@xx.xx.xx.10
CSeq: 877 SUBSCRIBE
Contact: 
Max-Forwards: 70
User-Agent: ewb2bua/15.4.3Alpha.2019053
Event: dialog
Expires: 300
Content-Length: 0


On Tue, 23 Jul 2019 at 04:54, Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:


Inline

On 7/21/19 6:42 PM, David Cunningham wrote:
 > Hello,
 >
 > We have the following issue and are looking for some advice on
the expected
 > behaviour:
 >
 > 1. UAC sends SUBSCRIBE to UAS at x.x.x.x:5061, receives 200 OK in
response.
 > 2. UAS sends NOTIFY to UAC with Record-Route x.x.x.x:5061, Via
 > x.x.x.x:5061, and Contact x.x.x.x:56095, receives 200 OK in response.
 > 3. UAC sends SUBSCRIBE to UAS at x.x.x.x:56095, receives no response
 > because port is not accessible directly from the UAC.
 >
 > These are all within one dialog. RFC 3261 12.2 says:
 >
 >     Requests within a dialog MAY contain Record-Route and Contact
header
 >     fields.  However, these requests do not cause the dialog's
route set
 >     to be modified, although they may modify the remote target URI.
 >     Specifically, requests that are not target refresh requests
do not
 >     modify the dialog's remote target URI, and requests that are
targ

Re: [Sip-implementors] NOTIFY and Record-Route

[Paul Kyzivat]

Inline

On 7/21/19 6:42 PM, David Cunningham wrote:

Hello,

We have the following issue and are looking for some advice on the expected
behaviour:

1. UAC sends SUBSCRIBE to UAS at x.x.x.x:5061, receives 200 OK in response.
2. UAS sends NOTIFY to UAC with Record-Route x.x.x.x:5061, Via
x.x.x.x:5061, and Contact x.x.x.x:56095, receives 200 OK in response.
3. UAC sends SUBSCRIBE to UAS at x.x.x.x:56095, receives no response
because port is not accessible directly from the UAC.

These are all within one dialog. RFC 3261 12.2 says:

Requests within a dialog MAY contain Record-Route and Contact header
fields.  However, these requests do not cause the dialog's route set
to be modified, although they may modify the remote target URI.
Specifically, requests that are not target refresh requests do not
modify the dialog's remote target URI, and requests that are target
refresh requests do.

The NOTIFY is a target refresh request, so presumably the remote target URI
is then considered to be x.x.x.x:56095 as specified in the Contact header.

But dos the Record-Route in the NOTIFY really have no effect on the
subsequent SUBSCRIBE? Can the NOTIFY not tell the UAS to route via
x.x.x.x:5061 instead of sending to x.x.x.x:56095 directly?


Your example is hard to understand because of the repeated use of 
x.x.x.x - it isn't clear if all instances of that are intended to be the 
same or if each is intended to carry different values. Please restate 
your problem, showing exactly what changes in the NOTIFY and what stays 
the same.


But for your basic question, the route set for a dialog is finalized 
during dialog establishment. Subsequently only the addresses of the 
endpoints can be changed. If you need to change the route set you can 
send an INVITE/Replaces or a REFER/Replaces to establish a totally new 
dialog to replace the old one.


Thanks,
Paul


Thank you in advance!

--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
___
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] The purpose of late offers

[Paul Kyzivat]

On 4/23/19 5:12 PM, Alex Balashov wrote:

Paul,

Why can’t it do that with an offer in the initial invite?


Because:

1) it doesn't have any idea what codecs, or even what media, either of 
the endpoints support.


2) since it isn't planning on terminating the media it has no media 
address to include in an initial offer.


Thanks,
Paul


—
Sent from mobile, with due apologies for brevity and errors.


On Apr 23, 2019, at 5:10 PM, Paul Kyzivat  wrote:

Alex,

A classic use case is 3PCC: A device in the middle wants to broker a call 
between two other endpoints. A priori it doesn't know the capabilities of 
either of those endpoints, and doesn't want to put itself in the media path as 
a transcoder. So it asks one end to provide an offer so it can offer that to 
the other end.

Thanks,
Paul


On 4/23/19 1:48 PM, Alex Balashov wrote:
Hi,
Trying to fill a gaping hole in my knowledge:
What is the actual purpose of late SDP offers (no SDP in initial INVITE,
SDP offer in 2xx reply, SDP answer in end-to-end ACK)?
RFC 3261 mentions them, of course, but I’ve only ever seen them used in
Cisco (CCM and IOS voice gateway) land.
I understand that this puts some control in the hands of the caller - it
gives the caller the flexibility to respond based on the callee's SDP
offer more 'flexibly', since it doesn't have to tip its hand about what
it wants first.
But from what I understand, an SDP stanza is, in principle, a statement
about what / how each endpoint wants to receive, not send. Right? I am
aware that there are some cases where, as a matter of convention more so
than standardisation, some inferences about sending intentions are
permitted on the basis of an SDP advertisement -- such as the 183 early
media case.
Still, in principle, SDP is about what I want to receive and how I want
to receive it, I thought. And in principle, any session can involve
wildly asymmetric and non-isomorphic media stream characteristics, i.e.
two different codecs, packetisation durations, etc. on the respective
legs.
If so, what purpose does it serve for the caller to not have to tip its
hand preemptively about what codecs it is willing to accept, for
example?
Does it mirror some PSTN interoperability need? A lot of the discussion
around it seems to be in the context of third-party call control (3pcc),
but the exact connection is unilluminated, and in any case, that's not a
concept I understand particularly well.
Much technical discussion exists online about what it does and why it
needs to be supported: it allows the caller to respond flexibly based on
the callee’s offer. But I can't find a word about why one might actually
want to do that, what sort of scenario it is meant to support, or
otherwise anything about the underlying philosophical motivation.
Any insight is appreciated!
-- Alex


___
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] The purpose of late offers

[Paul Kyzivat]

Alex,

A classic use case is 3PCC: A device in the middle wants to broker a 
call between two other endpoints. A priori it doesn't know the 
capabilities of either of those endpoints, and doesn't want to put 
itself in the media path as a transcoder. So it asks one end to provide 
an offer so it can offer that to the other end.


Thanks,
Paul

On 4/23/19 1:48 PM, Alex Balashov wrote:

Hi,

Trying to fill a gaping hole in my knowledge:

What is the actual purpose of late SDP offers (no SDP in initial INVITE,
SDP offer in 2xx reply, SDP answer in end-to-end ACK)?

RFC 3261 mentions them, of course, but I’ve only ever seen them used in
Cisco (CCM and IOS voice gateway) land.

I understand that this puts some control in the hands of the caller - it
gives the caller the flexibility to respond based on the callee's SDP
offer more 'flexibly', since it doesn't have to tip its hand about what
it wants first.

But from what I understand, an SDP stanza is, in principle, a statement
about what / how each endpoint wants to receive, not send. Right? I am
aware that there are some cases where, as a matter of convention more so
than standardisation, some inferences about sending intentions are
permitted on the basis of an SDP advertisement -- such as the 183 early
media case.

Still, in principle, SDP is about what I want to receive and how I want
to receive it, I thought. And in principle, any session can involve
wildly asymmetric and non-isomorphic media stream characteristics, i.e.
two different codecs, packetisation durations, etc. on the respective
legs.

If so, what purpose does it serve for the caller to not have to tip its
hand preemptively about what codecs it is willing to accept, for
example?

Does it mirror some PSTN interoperability need? A lot of the discussion
around it seems to be in the context of third-party call control (3pcc),
but the exact connection is unilluminated, and in any case, that's not a
concept I understand particularly well.

Much technical discussion exists online about what it does and why it
needs to be supported: it allows the caller to respond flexibly based on
the callee’s offer. But I can't find a word about why one might actually
want to do that, what sort of scenario it is meant to support, or
otherwise anything about the underlying philosophical motivation.

Any insight is appreciated!

-- Alex



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

Re: [Sip-implementors] Precondition is added into 200OK re-INVITE

[Paul Kyzivat]

On 4/18/19 8:00 PM, anhright wrote:

Hi Paul,

My concern is not about fax machine, it is about my system when it 
receives re-INVITE with no precondition, but it adds precondition to the 
200 OK.


Putting them in does no harm. But it may indicate problems if it expects 
something to happen as a result.


Thanks,
Paul


Thanks,
A.C



Sent from my Samsung Galaxy smartphone.

 Original message 
From: Paul Kyzivat 
Date: 4/18/19 23:21 (GMT+07:00)
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Precondition is added into 200OK re-INVITE

On 4/17/19 10:50 PM, Anh Cao wrote:
 > Hi all,
 >
 > I meet a weird case with precondition but can not find any document talk
 > about it:
 >
 > I make SIP call from my system to the fax machine. In the initial INVITE,
 > my system includes precondition in Supported header and status in 
SDP. But

 > fax machine does not support precondition so it removes precondition from
 > Supported header and status from SDP.
 >
 > After voice call is established, fax machine sends T.38 re-INVITE to my
 > system to start fax with Supported header has no precondition and SDP has
 > no status.
 > And my system answers fax machine by 200 OK with Supported has 
precondition

 > and T.38 SDP has status for precondition:
 > m=image 55314 udptl t38
 > a=T38FaxVersion:0
 > a=T38MaxBitRate:14400
 > a=curr:qos local sendrecv
 > a=curr:qos remote sendrecv
 > a=des:qos none local sendrecv
 > a=des:qos none remote sendrecv
 >
 > Is it the acceptable behavior? and there is any document talk a bout this
 > case? with re-INVITE for voice all and for fax call, the behaviors 
are the

 > same or different?

I don't see anything wrong with this. The "Supported" is declaring your
*support* for preconditions. The fax machine is acting as it should
given that it doesn't support or understand preconditions. It is
apparently ignoring the a= lines carrying precondition status, which is
what an implementation is supposed to do with attributes it doesn't
understand.

What else do you think should be done?

This is basic behavior for extensions.

Thanks,
Paul

___
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] Precondition is added into 200OK re-INVITE

[Paul Kyzivat]

On 4/17/19 10:50 PM, Anh Cao wrote:

Hi all,

I meet a weird case with precondition but can not find any document talk
about it:

I make SIP call from my system to the fax machine. In the initial INVITE,
my system includes precondition in Supported header and status in SDP. But
fax machine does not support precondition so it removes precondition from
Supported header and status from SDP.

After voice call is established, fax machine sends T.38 re-INVITE to my
system to start fax with Supported header has no precondition and SDP has
no status.
And my system answers fax machine by 200 OK with Supported has precondition
and T.38 SDP has status for precondition:
m=image 55314 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos none local sendrecv
a=des:qos none remote sendrecv

Is it the acceptable behavior? and there is any document talk a bout this
case? with re-INVITE for voice all and for fax call, the behaviors are the
same or different?


I don't see anything wrong with this. The "Supported" is declaring your 
*support* for preconditions. The fax machine is acting as it should 
given that it doesn't support or understand preconditions. It is 
apparently ignoring the a= lines carrying precondition status, which is 
what an implementation is supposed to do with attributes it doesn't 
understand.


What else do you think should be done?

This is basic behavior for extensions.

Thanks,
Paul

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

Re: [Sip-implementors] XML Body in the 200 OK SIP Response of SIP MESSAGE

[Paul Kyzivat]

On 4/13/19 9:31 PM, abhishek jain wrote:
Thanks Paul for your great suggestions. Since, I don't want to add 
traffic to network, so I don't want to use a separate set of SIP MESSAGE 
request/response.


I doubt that this would have any appreciable affect on your network 
traffic unless you are using MESSAGE is a really inappropriate way. If 
your traffic is that high then you probably ought to be establishing a 
direct channel for these messages.


Based on our requirements, I find your suggestion of 
Content-ID header field option being really suitable. I am putting the 
request/response snippet below as per my understanding from your 
suggestion and various RFCs, please let me know if that looks good.


For example -
*Server to Client :*
MESSAGE 
:
Content-Type: application/chat-info+xml
Content-Length: ...

    
     :
    

*Client to Server:*
SIP/2.0 200 OK
:
Call-Info:<mailto:cid%3acn35t8j...@example.com>>; purpose=info

Content-Type: application/chat-info+xml
Content-Length: ...
content-ID:mailto:cn35t8j...@example.com>>

    
     :
    


Why is the mailto stuff present above???

I would expect just

Call-Info:; purpose=info
...
content-ID:

Otherwise it looks reasonable.

Thanks,
Paul


Regards
Abhishek

On Sat, Apr 13, 2019 at 4:36 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:


On 4/13/19 4:43 PM, abhishek jain wrote:
 > Thanks Paul for your quick response on a Saturday. I really
appreciate.
 > I am wondering how to implement below without introducing another
pair
 > of SIP request/response, if you could suggest that would be great
with
 > SIP compliance -
 >
 > 1. My server sending some configurations to client using SIP MESSAGE
 > 2. Client may apply some of them, so client should respond back
with the
 > config that have been applied.
 >
 > Would you suggest to include a proprietary SIP header containing the
 > information to be conveyed to server ? What could be the max data a
 > header may contain ?

I don't want to encourage you to use proprietary means. The most
straightforward way would be to use a separate MESSAGE in the reverse
direction.

You *could* add a header field to the MESSAGE response. That wouldn't
violate the rules of MESSAGE. And you could have that header field
reference a body using a Content-ID URL (cid:). You can read about this
in RFC5621. But you then need to find a suitable header field that
contains a URL. (I don't recommend making up a new header field. It
won't be valid sip even though correct implementations should ignore
header fields they don't understand.)  You might be able to use
Call-Info with purpose=info because it is very loosely defined. In that
case you would use Content-Type to indicate the format of your body.
But
of course you then need your own MIME-type to use for that.

If this is going to be an extended conversation then it would be better
to establish a dialog and then send your data within it. In that case
you could use INFO (RFC6086, *not* RFC2976). Note that this still
requires a separate request in each direction.

Or, you could establish a media channel to send your data using MSRP.

Or you could establish a data channel via
draft-ietf-mmusic-data-channel-sdpneg-25.

There is no theoretical limit to the size of a header field or a body.
But once they get very big you will need a TCP or TLS connection rather
than UDP. And sip implementations may impose some limit.

         Thanks,
         Paul


 > Regards
     > Abhishek
 >
 > On Sat, Apr 13, 2019 at 3:08 PM Paul Kyzivat
mailto:pkyzi...@alum.mit.edu>
 > <mailto:pkyzi...@alum.mit.edu <mailto:pkyzi...@alum.mit.edu>>> wrote:
 >
 >     On 4/13/19 3:58 PM, abhishek jain wrote:
 >      >>
 >      >> Hi,
 >      >> Can a Sip Response (to a Non-Dialog creating SIP Request)
 >     contain a body ?
 >      >> I would appreciate a quick response.
 >
 >     Sometimes. The rules vary depending on the type of message.
 >
 >     But not for MESSAGE. RFC3480 (section 7) says:
 >
 >          A 2xx response to a MESSAGE request MUST NOT contain a body.
 >
 >              Thanks,
 >              Paul
 >
 >
 >      >> For example -
 >      >> *Server to **Client **:*
 >      >> MESSAGE 
 >      >> :
 >      >>
 >      >> Content-Type: application/chat-info+xml
 >      >>
 >      >> Content-Length: ...
 >      >>
 >      >> 
 >      >>     
 >      >>
 >      >>      :
   

Re: [Sip-implementors] XML Body in the 200 OK SIP Response of SIP MESSAGE

[Paul Kyzivat]

On 4/13/19 4:43 PM, abhishek jain wrote:

Thanks Paul for your quick response on a Saturday. I really appreciate.
I am wondering how to implement below without introducing another pair 
of SIP request/response, if you could suggest that would be great with 
SIP compliance -


1. My server sending some configurations to client using SIP MESSAGE
2. Client may apply some of them, so client should respond back with the 
config that have been applied.


Would you suggest to include a proprietary SIP header containing the 
information to be conveyed to server ? What could be the max data a 
header may contain ?


I don't want to encourage you to use proprietary means. The most 
straightforward way would be to use a separate MESSAGE in the reverse 
direction.


You *could* add a header field to the MESSAGE response. That wouldn't 
violate the rules of MESSAGE. And you could have that header field 
reference a body using a Content-ID URL (cid:). You can read about this 
in RFC5621. But you then need to find a suitable header field that 
contains a URL. (I don't recommend making up a new header field. It 
won't be valid sip even though correct implementations should ignore 
header fields they don't understand.)  You might be able to use 
Call-Info with purpose=info because it is very loosely defined. In that 
case you would use Content-Type to indicate the format of your body. But 
of course you then need your own MIME-type to use for that.


If this is going to be an extended conversation then it would be better 
to establish a dialog and then send your data within it. In that case 
you could use INFO (RFC6086, *not* RFC2976). Note that this still 
requires a separate request in each direction.


Or, you could establish a media channel to send your data using MSRP.

Or you could establish a data channel via 
draft-ietf-mmusic-data-channel-sdpneg-25.


There is no theoretical limit to the size of a header field or a body. 
But once they get very big you will need a TCP or TLS connection rather 
than UDP. And sip implementations may impose some limit.


Thanks,
Paul



Regards
Abhishek

On Sat, Apr 13, 2019 at 3:08 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:


On 4/13/19 3:58 PM, abhishek jain wrote:
 >>
 >> Hi,
 >> Can a Sip Response (to a Non-Dialog creating SIP Request)
contain a body ?
 >> I would appreciate a quick response.

Sometimes. The rules vary depending on the type of message.

But not for MESSAGE. RFC3480 (section 7) says:

     A 2xx response to a MESSAGE request MUST NOT contain a body.

         Thanks,
         Paul


 >> For example -
 >> *Server to **Client **:*
 >> MESSAGE 
 >> :
 >>
 >> Content-Type: application/chat-info+xml
 >>
 >> Content-Length: ...
 >>
 >> 
 >>     
 >>
 >>      :
 >>
 >>     
 >>
 >>
 >> *Client to Server:*
 >>
 >> SIP/2.0 200 OK
 >>
 >> :
 >>
 >> Content-Type: application/chat-info+xml
 >>
 >> Content-Length: ...
 >>
 >> 
 >>     
 >>
 >>      :
 >>
 >>     
 >>
 >> Regards
 >>
 >> Abhishek
 >>
 >>
 >>
 >>
 > ___
 > 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] XML Body in the 200 OK SIP Response of SIP MESSAGE

[Paul Kyzivat]

On 4/13/19 3:58 PM, abhishek jain wrote:


Hi,
Can a Sip Response (to a Non-Dialog creating SIP Request) contain a body ?
I would appreciate a quick response.


Sometimes. The rules vary depending on the type of message.

But not for MESSAGE. RFC3480 (section 7) says:

   A 2xx response to a MESSAGE request MUST NOT contain a body.

Thanks,
Paul



For example -
*Server to **Client **:*
MESSAGE 
:

Content-Type: application/chat-info+xml

Content-Length: ...




 :




*Client to Server:*

SIP/2.0 200 OK

:

Content-Type: application/chat-info+xml

Content-Length: ...




 :



Regards

Abhishek





___
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 an INVITE which did not got provisional response yet

[Paul Kyzivat]

On 3/13/19 5:45 PM, AXE MSC wrote:

Hi,

PCSCF has two realms. One is facing Core network and another is facing
Access network. I have a scenario where PCSCF sends the INVITE to the
handset facing Access realm. But no TCP ACK or SIP provisional response
received from the handset. After 15 seconds wait time SCSCF asks PCSCF core
realm to clear the call by sending a Cancel. PCSCF replies back with 200 Ok
for the Cancel. But PCSCF kept the transaction alive for the handset due to RFC
3261, Section 9.1: "If no provisional response has been received, the
CANCEL request MUST NOT be sent; rather, the client MUST wait for the
arrival of a provisional response before sending the request."


Is the PCSCF acting as a proxy or B2BUA?


After 4 minutes, handset replies back with TCP ACK. PCSCF then re-transmits
INVITE and and gets 183 back from handset. However, because calling party
side call was already cleared at 15th second, this is causing a ghost call
for B party after 4 minutes of the original call.


Can PCSCF destroy the transaction at 15th second without sending the Cancel
to handset? Later if handset comes with provisional response  then PCSCF
can just reply back with SIP 481(transaction does not exist).


To be correct you need to maintain the transaction until you get 
something back or it times out. If PCSCF is acting as proxy, then the 
SCSCP should be retransmitting the INVITE (according to timers) until 
something comes back or the transaction times out. Sending CANCEL and 
receiving a 200 to it doesn't mean you can avoid this. If the CANCEL 
succeeds then a 487 should be received for the INVITE, ending the 
transaction.


OTOH, if the PCSCF is acting as a B2BUA, then the PCSCF *may* send a 487 
to the INVITE when it gets the CANCEL. It will then have to handle the 
transaction to the handset itself. It will still need to do all the 
above on its own. If that then results in the handset accepting the call 
it can send a BYE to terminate it.


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

Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header

[Paul Kyzivat]

On 2/8/19 2:43 AM, Rakesh wrote:

Sorry typo. "ff" I mean.


Since we are talking about HEX, ff & FF are the same.

More below.


BR///

Rakesh Kumar Mohanty



On Fri, Feb 8, 2019 at 1:12 PM Rakesh <mailto:rak...@gmail.com>> wrote:


Hi Paul,
Thank you very much.
Another think I am thinking is FF is also not valid as per RFC 3261
it is UTF-8 Character set.
Am I correct in understanding ?


Not quite - its not that simple. For one thing, UTF8 MAY appear in some 
sip header fields, at least in principle:


   extension-header  =  header-name HCOLON header-value
   header-name   =  token
   header-value  =  *(TEXT-UTF8char / UTF8-CONT / LWS)

OTOH, IIUC FF will never appear in UTF8 and so cannot validly appear in 
a sip header field. But it MAY appear in a sip *message-body*:


   message-body  =  *OCTET

So, if you have "lost sync" in a TCP sip connection there is no sure way 
to find the beginning of the next sip message. If you encounter FF, or a 
non-UTF8 octet, then you certainly aren't at the *beginning* of a sip 
message. But you *might* be looking at part of a body of a sip message 
that was garbled. You can keep looking for either a message-header or 
Status-Line and *hope* that it is the start of a message. But it might 
not be. It could be part of a message-body.


I am confused about what you are looking to understand with these 
questions. If you can explain that then perhaps we can provide more help.


Thanks,
Paul


BR///

Rakesh Kumar Mohanty



    On Thu, Feb 7, 2019 at 11:07 PM Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote:

Rakesh privately asked me why this doesn't conform to the ABNF
of a sip
message. I'm replying to the list for the benefit of others.

Here is some of the relevant ABNF:

SIP-message    =  Request / Response
Request        =  Request-Line
                    *( message-header )
                    CRLF
                    [ message-body ]
Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
Method            =  INVITEm / ACKm / OPTIONSm / BYEm
                       / CANCELm / REGISTERm
                       / extension-method
extension-method  =  token
Response          =  Status-Line
                       *( message-header )
                       CRLF
                       [ message-body ]
Status-Line     =  SIP-Version SP Status-Code SP Reason-Phrase CRLF
SIP-Version    =  "SIP" "/" 1*DIGIT "." 1*DIGIT
token       =  1*(alphanum / "-" / "." / "!" / "%" / "*"
                       / "_" / "+" / "`" / "'" / "~" )

Examining this you can see that a message must start with one of
the
following:

- a token - a method name
- "SIP/" - beginning a sip version

What you show is neither of those, so it isn't valid sip.

Over UDP every packet must start with a message. Over TCP, messages
immediately follow one another. Every request or response ends
with CRLF
followed by an optional body. You must parse Content-Length in
order to
skip over the body (which may also contain CRLF).

If you encounter something that doesn't parse as a message with TCP
input you have to close the connection without parsing any more,
or else
use a heuristic to skip over stuff until you find what seems to
be the
beginning of a new message.

         Thanks,
         Paul


        >    *ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  *
 >     
 >      > 0010  * ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff*
 >       
 >      > 0020      ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff
 >      >   
 >      > 0010   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 >       
 >      > 0020   ff ff ff ff ff ff ff ff ff ff ff 58 2d 42 72 6f
 >       ÿÿÿX-xro
 >      > 0030   61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65
74   : net
 >      > 0040   77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69
 >       work-address="si
 >      > 0050   70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d
 > p:@xx.yyy.net <mailto:p...@xx.yyy.net>
<mailto:p...@xx.yyy.net <mailto:p%2...@xx.yyy.net>>
 >      > 0070   74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73
 >       t;user=phone";us
 

Re: [Sip-implementors] RFC ABNF grammar check for Truncated unrecognized header

[Paul Kyzivat]

Rakesh privately asked me why this doesn't conform to the ABNF of a sip 
message. I'm replying to the list for the benefit of others.


Here is some of the relevant ABNF:

SIP-message=  Request / Response
Request=  Request-Line
  *( message-header )
  CRLF
  [ message-body ]
Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
Method=  INVITEm / ACKm / OPTIONSm / BYEm
 / CANCELm / REGISTERm
 / extension-method
extension-method  =  token
Response  =  Status-Line
 *( message-header )
 CRLF
 [ message-body ]
Status-Line =  SIP-Version SP Status-Code SP Reason-Phrase CRLF
SIP-Version=  "SIP" "/" 1*DIGIT "." 1*DIGIT
token   =  1*(alphanum / "-" / "." / "!" / "%" / "*"
 / "_" / "+" / "`" / "'" / "~" )

Examining this you can see that a message must start with one of the 
following:


- a token - a method name
- "SIP/" - beginning a sip version

What you show is neither of those, so it isn't valid sip.

Over UDP every packet must start with a message. Over TCP, messages 
immediately follow one another. Every request or response ends with CRLF 
followed by an optional body. You must parse Content-Length in order to 
skip over the body (which may also contain CRLF).


If you encounter something that doesn't parse as a message with TCP 
input you have to close the connection without parsing any more, or else 
use a heuristic to skip over stuff until you find what seems to be the 
beginning of a new message.


Thanks,
Paul


  >    *ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  *


 > 0010  * ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff* 
  

 > 0020      ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 >   
 > 0010   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
  
 > 0020   ff ff ff ff ff ff ff ff ff ff ff 58 2d 42 72 6f 
  ÿÿÿX-xro

 > 0030   61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74   : net
 > 0040   77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69 
  work-address="si

 > 0050   70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d
p:@xx.yyy.net 
 > 0070   74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73 
  t;user=phone";us
 > 0080   65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36 
  er-id=""

 > 0090   40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e   @xx.yyy.
 > 00a0   6e 65 74 22 0d 0a                                 net"..
 > ÿÿÿX-xro
 > 0030   61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74   : net
 > 0040   77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69 
  work-address="si

 > 0050   70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d
p:@xx.yyy.net 
 > 0070   74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73 
  t;user=phone";us
 > 0080   65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36 
  er-id=""

 > 0090   40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e   @xx.yyy.
 > 00a0   6e 65 74 22 0d 0a                                 net"..
 >
 > [image: image.png]
 >
 > BR///
 >
 > Rakesh Kumar Mohanty
 >
 >
 > On Wed, Feb 6, 2019 at 3:21 PM Rakesh mailto:rak...@gmail.com>> wrote:
 >
 >> Hi Expert,
 >>
 >> Can I just know on  INVITE request if I get the below characters
then is
 >> it OK as per ABNF grammar?  Please note I am not asking about
the header
 >> rather I need to know the correctness of the character that has
appeared on
 >> INVITE request.
 >>
 >>
 >>

[truncated]\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\37
 >> Expert Info (Note/Undecoded): Unrecognised SIP header
 >> (���)
 >>
 >> [image: image.png]
 >> [image: image.png]
 >>
 >> BR///
 >>
 >> Rakesh Kumar Mohanty
 >>
 >
 >
 > ___
 > 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] RFC ABNF grammar check for Truncated unrecognized header

[Paul Kyzivat]

Rakesh,

I still don't understand your question. What you show below appears to 
be garbage that happens to include a few fragments that resemble sip 
URIs. Did you receive this on a port where you expect to receive sip 
messages? If so, this clearly doesn't conform to the ABNF syntax of a 
sip message.


Thanks,
Paul

On 2/6/19 5:12 AM, Rakesh wrote:

Hi,

Further to add to the last this is what I am looking for the bold part

   *ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  * 
0010  * ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff*   
0020      ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  
0010   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff   
0020   ff ff ff ff ff ff ff ff ff ff ff 58 2d 42 72 6f   ÿÿÿX-xro
0030   61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74   : net
0040   77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69   work-address="si
0050   70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d   p:@xx.yyy.net
0070   74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73   t;user=phone";us
0080   65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36   er-id=""
0090   40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e   @xx.yyy.
00a0   6e 65 74 22 0d 0a net"..
ÿÿÿX-xro
0030   61 64 57 6f 72 6b 73 2d 44 4e 43 3a 20 6e 65 74   : net
0040   77 6f 72 6b 2d 61 64 64 72 65 73 73 3d 22 73 69   work-address="si
0050   70 3a 2b 33 34 39 33 37 38 31 37 30 31 36 40 6d   p:@xx.yyy.net
0070   74 3b 75 73 65 72 3d 70 68 6f 6e 65 22 3b 75 73   t;user=phone";us
0080   65 72 2d 69 64 3d 22 39 33 37 38 31 37 30 31 36   er-id=""
0090   40 6d 66 65 2e 74 65 6c 65 66 6f 6e 69 63 61 2e   @xx.yyy.
00a0   6e 65 74 22 0d 0a net"..

[image: image.png]

BR///

Rakesh Kumar Mohanty


On Wed, Feb 6, 2019 at 3:21 PM Rakesh  wrote:


Hi Expert,

Can I just know on  INVITE request if I get the below characters then is
it OK as per ABNF grammar?  Please note I am not asking about the header
rather I need to know the correctness of the character that has appeared on
INVITE request.


[truncated]\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\37
Expert Info (Note/Undecoded): Unrecognised SIP header
(���)

[image: image.png]
[image: image.png]

BR///

Rakesh Kumar Mohanty




___
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] Reflection of non-registered SDP attributes

[Paul Kyzivat]

On 1/30/19 10:23 PM, Dale R. Worley wrote:

It's a fascinating problem.  In a way, inserting a unregistered
attribute is forbidden, but any recipient is forbidden from objecting to
it.

OTOH, if the attribute is unregistered, you can't really say that the
endpoint using it in its answer is *wrong*, since there's no fixed
definition of the semantics of the attribute.  Perhaps the endpoint
simply means "I received CustomAttribute:GID in the offer."



I think the actual answer is to be clever, and to define CustomAttribute
in such a way that simply copying it into the answer unchanged can be
detected and ignored.


The device that copies unknown attributes from the offer to the answer 
is even more broken than those that use unregistered attributes. It can 
break valid usage. So I would really lean on it to clean up its act.


Many attributes are defined so that mirroring the attribute in the 
answer explicitly indicates support for it. So defining one so that 
usage is ignored seems futile.


Presumably the offerer including the attribute is hoping for an answerer 
that has the same understanding of it. But the two devices could have 
independently chosen to appropriate the same name for two different 
purposes.  I guess they hope that if the name is sufficiently unique 
then the probability of this happening is small enough to ignore.


Thanks,
Paul

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

Re: [Sip-implementors] Reflection of non-registered SDP attributes

[Paul Kyzivat]

On 1/29/19 11:29 AM, Alex Balashov wrote:

Hello,

On Tue, Jan 29, 2019 at 11:21:01AM -0500, Paul Kyzivat wrote:


5.13 says: "Attributes MUST be registered with IANA", so why do you
say this isn't illegal?


Upon reflection, you are certainly correct. I suppose the notion of
legality I had in mind was implicitly to do with grammatical validity /
request intelligibility rather than policy.

So, if the attribute is not registered and if the foregoing applies to
unsupported but registered attributes, and is therefore illegal, then,
in the context of one of those acrimonious "how dare you say I'm not
following the standards?" disputes, does this--in any _reasonable_ way,
taking purely political phenomena out of it--open the door to the
receiver/answerer vendor arguing that an endpoint making use of an
unregistered attribute (that is to say, illegally so) is not justified
in expecting predictable or standards-prescribed results in the answer?


In this case I think the UAC *should* expect that a conforming recipient 
will act in a conforming way and *ignore* the attribute - and thus *not* 
include it in the answer. This is because a conforming recipient cannot 
distinguish the non-conforming use by the UAC from use of a standard 
extension not known to the recipient.


So the UAC *can* game the system and use this to negotiate with another 
UA implementing the same unregistered non-conforming extension.


But you can still call them out for being non-conforming.

Thanks,
Paul

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

Re: [Sip-implementors] Reflection of non-registered SDP attributes

[Paul Kyzivat]

On 1/29/19 10:21 AM, Alex Balashov wrote:

Hi,

I am using a media relay which implements some internal loop detection
by adding a non-IANA-registered SDP attribute to any offer or answer
that passes through it:

a=CustomAttribute:GUID


From what I understood from RFC 4566 § 5.13, this isn't illegal, but

such an attribute must be ignored.


5.13 says: "Attributes MUST be registered with IANA", so why do you say 
this isn't illegal?


The requirement to ignore unknown attributes is intended to cover the 
case where there has been a legal extension (with registration) that is 
used by the sender but not implemented by the receiver.



Now, there is a particular type of endpoint in use in this environment
which takes that attribute from an incoming initial INVITE--which is, by
definition, not locally intelligible--and copies it dumbly into its
2xx/SDP answer.

Commonsensically, this seems like broken behaviour; if it doesn't
understand the attribute, it must be ignored, per § 5.13. Beyond that,
is there any specific proscription against doing this in the standard?


Again consider this behavior in conjunction with a valid extension. The 
inclusion of an attribute in an answer after receiving it in an offer is 
often used as an indication of support for the extension. This depends 
on answerers ignoring (not mirroring) attributes they don't understand. 
So an endpoint with this behavior will break any peer using such a legal 
extension.


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

Re: [Sip-implementors] Dynamic payload number during renegotiation. RFC 3264

[Paul Kyzivat]

Oleksandr,

On 1/17/19 3:47 AM, Oleksandr Fadieiev wrote:

Hello dear team.

Could you please help determine if RFC 3264 violated in the following
scenario?

Unfortunately, I wasn’t able to find appropriate email thread to answer my
question.

And I'm sorry for lengthy explanation.

Scenario.

1)

PartyA creates a dialog to SIP Server (further – “SIPS”; it is B2BUA;
application server; it does not generate SDP by itself, only re-sends the
offers between the parties)

2)

SIPS creates a dialog to PartyB

3)

Offer from PartyA:

“v=0

o=Sonus_UAC 11094 21605 IN IP4 10.113.254.130

s=SIP Media Capabilities

c=IN IP4 10.113.254.130

t=0 0

m=audio 27282 RTP/AVP 8 18 2 102

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:2 G726-32/8000

a=rtpmap:102 telephone-event/8000

a=fmtp:102 0-15

a=sendrecv

a=ptime:20”

Please note that *102* is mapped to telephone-event

4)

Offer from PartyB:
“v=0

o=- 272923319 1 IN IP4 10.113.248.23

s=phone-call

c=IN IP4 10.113.248.23

t=0 0

m=audio 14530 RTP/AVP 8 102

a=rtpmap:8 pcma/8000

a=ptime:20

a=rtpmap:102 telephone-event/8000

a=fmtp:102 0-15

a=sendrecv”

5)

Session is started, no issues

6)

SIPS now ends the dialog to PartyB and creates new one to PartyC

7)

Dialog between PartyA and SIPS remains

8)

PartyC in INVITEd with no SDP and responds with its offer:
“v=0

o=- 272961713 1 IN IP4 10.113.248.24

s=phone-call

c=IN IP4 10.113.248.24

t=0 0

m=audio 11688 RTP/AVP 8 101

a=rtpmap:8 pcma/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv”

Please note, now *101* is mapped to telephone-event

9)

This offer is used in the re-INVITE towards Party A

Can you please tell if “old” mapping of 102-to-telephone-event should be
present in this re-INVITE?

---

My opinion is that mapping may be absent and no RFC violation happens.


I agree with you.


While my opponent says that because of the following quote:
“8.3.2 Changing the Set of Media Formats

…

in the  case of RTP, the mapping from a particular dynamic payload type
number to a particular codec within that media stream MUST NOT change
for the duration of a session”

 From my point of view, “mapping” is not violated in terms that 102 was NOT
mapped to some different codec like g711; this mapping was simply omitted.


Yes. While a particular PT can't be mapped to a different codec, a coded 
*may* be mapped to a different PT.



And it is allowed to add, remove media formats as well as map multiple
numbers to the same codec.


Agree.


---

Could you please tell if, in the given scenario, the mapping of
102-to-telephone-event should (MUST?) be present in the subsequent
re-negotiations with PartyA?

Can you please also tell the meaning of “mapping from a particular dynamic
payload type

number to a particular codec” from RFC?

Does it mean that once number-to-codec mapping appears it must not be
changed as a mapping fact?

Or does it mean that it also has to be present in all further offers?


See above - I agree with your interpretation.

BUT!!! SIPS is living dangerously in step (8) above. By sending an 
offerless invite to a new party that has no knowledge of the existing PT 
mappings in the session with PartyA it is running a huge risk that 
PartyC *will* use PTs in an inconsistent way.


To avoid this it has a couple of options:

1) include an offer in the invite to partyC, consistent with the PT 
mappings in the session with PartyA. (Note that this isn't a total 
solution. If some PT mappings were established earlier in the session 
with PartyA but are not currently in use at the time of the call to 
PartyC then there is no way to communicate those.)


2) if SIPS receives an offer or answer that conflicts with established 
mappings on the other side, then send an INVITE/Replaces to the other 
side rather than a re-INVITE.


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

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

[Paul Kyzivat]

On 12/21/18 2:34 PM, Roman Shpount wrote:

RFC  5057 is informational, not a standard. RFC 3261 specifies that dialog
established using an INVITE transaction can only be terminated using a BYE
message.

Specifically in https://tools.ietf.org/html/rfc3261#section-12.2.1.2:

If the response for a request within a dialog is a 481 (Call/Transaction
Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the
dialog.  A UAC SHOULD also terminate a dialog if no response at all is
received for the request (the client transaction would inform the TU about
the timeout.)

   For INVITE initiated dialogs, terminating the dialog consists of
sending a BYE.


This does not specify what happens when re-INVITE gets a 404 response,
since this is not something that should normally happen for the request
with the dialog. Getting 404 to a re-INVITE means something went horribly
wrong and terminating dialog by sending BYE is probably the right course of
action.


+1

There is a pretty good chance that you will also get a 404 response to 
the BYE, but you nevertheless need to send it.


Thanks,
Paul



Regards,
_
Roman Shpount


On Fri, Dec 21, 2018 at 2:23 PM Moy Amiga  wrote:


Thank you Roman.

But about the RFC 5057,  https://tools.ietf.org/html/rfc5057#section-5.1
And I dont know if this RFC is for the NOTIFY only or also include a
INVITE message.


For the failure responses with code 400 and greater, there are three
common ways the failure can affect the transaction, usage, and dialog
state.

Transaction Only  The error affects only the transaction, not the
   usage or dialog the transaction occurs in (beyond affecting the
   local CSeq).  Any other usage of the dialog is unaffected.  The
   error is a complaint about this transaction, not the usage or
   dialog that the transaction occurs in.

Destroys Usage  The error destroys the usage, but not the dialog.
   Any other usages sharing this dialog are not affected.

Destroys Dialog  The error destroys the dialog and all usages sharing
   it.

Table 1 and Table 2 display how the various codes affect transaction,
usage, or dialog state.  Response code specific comments or
exceptions follow the table.

 +--++-+
 |   Transaction Only   | Destroys Usage | Destroys Dialog |
 +--++-+
 | 400 (or unknown 4xx) |405, 480|  404, 410, 416  |
 |  401, 402, 403, 406  |481, 489| 482, 483|
 |   407, 408, 412-415  |   501  | 484, 485|
 |  417, 420, 421, 422  || 502, 604|
 | 423, 428, 429|| |
 |   436-438, 486, 487  || |
 |  488, 491, 493, 494  || |
 | 500 (or unknown 5xx) || |
 | 503, 504, 505|| |
 |   513, 580   || |
 | 600 (or unknown 6xx) || |
 |   603, 606   || |
 +--++-+






--
*Moisés Amiga*

*Voice Operations*

*Mex T.* + 52 (55) 5147 8040  ext 1367
*Cel.* +521 55 2575 6848
  Llámame 

Paseo de las Palmas 215-304
Col. Lomas de Chapultepec,
México D.F. 11000





El vie., 21 de dic. de 2018 a la(s) 12:52, Roman Shpount (
ro...@telurix.com) escribió:


Sorry, BYE message. I blame this on consistent fat-fingering.

:)
_
Roman Shpount


On Fri, Dec 21, 2018 at 1:31 PM Alex Balashov 
wrote:


BUY message? What is this, Broadsoft? :-)

On Fri, Dec 21, 2018 at 01:29:26PM -0500, Roman Shpount wrote:


You will need to send the BUY message. 404 response only cancels the
re-INVITE transaction, not the call. This being said, most SIP
implementations will hang up the call (send BUY) when they receive 404
response to a re-INVITE.

Regards,
_
Roman Shpount


On Fri, Dec 21, 2018 at 12:54 PM Moy Amiga 

wrote:



Hi.

I Have a question.
When I have a already established call, and we send a Re-Invite, if

this

Re-Invite was rejected with 404.
To finish the call, we need a BYE message or only with this reject

404  the

session is considered canceled?

Thank you and best regards


--
*Moisés Amiga*

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


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


--
Alex 

Re: [Sip-implementors] Question on Offer/Answer Model with SIP

[Paul Kyzivat]

On 12/21/18 12:27 AM, Amarnath Kanchivanam wrote:

Thanks Paul, yes it helps.
I have one more question - What should be the SDP answer for empty 
Re-Invite (without SDP) in hold and non hold scenario?


The SDP in the response to a INVITE/reINVITE is an *offer*, not an *answer*.

As I noted before, it doesn't really matter whether it is a hold or 
non-hold case. The one sending the offer should offer what *it* wants at 
that time, without regard to what it might guess that the other end 
might want. The other end can deal with its desires in the answer.


To cover some common cases,

1) assume that Alice and Bob are in a call and Alice put the call on hold:

1a) if Bob receives an offerless reinvite, he most likely should put 
sendrecv in the offer he sends back. Note that it is valid but odd for 
Alice to send this, but it makes more sense if it was sent by a 
middlebox. (I presume Bob doesn't *want* hold, or he would already have 
sent another invite to indicate that.)


1b) if Alice receives an oferless reinvite, she will most likely want to 
put sendonly in the offer she sends back. (If she had changed her mind 
about wanting to be on hold she would have then sent a reinvite with an 
offer with sendrecv.


1c) Suppose Bob now also wants to put the call on hold. (Doesn't want to 
receive media from Alice.) He will send a reinvite with an offer to 
accomplish this. He may put either sendonly or inactive in that offer. 
Either way, assuming Alice still wants the call on hold she must put 
inactive in her answer.


1d) suppose in the initial invite of the call Alice had offered both 
audio and video, and Bob had accepted the audio and rejected the video. 
When Alice sends subsequent offers within the call she may well want to 
continue to offer video, just in case Bob has a change of heart and 
might accept it, though this might seem to be unlikely. This becomes 
more interesting when there is a middlebox in the call, such as a device 
managing 3pcc (third party call control). It is common for such a device 
to send an offerless invite to Alice when it wants to transfer the call 
from Bob to Charlie. In that case it may be that Charlie would accept 
the video.


But this needs to be tempered by the UI between Alice and her phone. It 
may be that she is no longer prepared for video in the call. Perhaps the 
video resource is being used for something else. So in the end this is 
an implementation choice.


There are similar issues regarding alternative codecs for the media. 
Ideally the offerer will include all supported codecs in every offer. 
But optimization of the implementation may result it in wanting to limit 
what it puts in subsequent offers, based on what is being used. Doing so 
can cause trouble in the 3pcc case.


Note that while I say that offers should reflect what the offerer wants 
without regard to what it thinks the answerer will want, there are some 
constraints on this documented in 3261 and 3265. For instance, if a 
payload type has been used earlier in the call for an rtp session then 
it can't be used for a *different* codec or codec configuration later in 
the session.


Thanks,
Paul


Regards,
Amarnath

On Wed, Dec 19, 2018 at 10:19 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:


Amarnath,

Take a look at RFC6337 for an in-depth treatment of offer/answer issues
and best practices. More below, consistent with what is in that rfc.

On 12/19/18 12:28 AM, Amarnath Kanchivanam wrote:
 > Hi,
 >
 > I have below call flow and would like to know the correct behavior.
 >
 > UAC                                          UAS
 > INVITE     ->
 >                              <---200 OK
 > Ack      -->
 >
 > Now UAS puts call on Hold
 >
 >                               <---Re-Invite with
send-only
 > attribute
 > 200 OK --> recv-only
 >                                 <--Ack
 >
 > Now UAS does Un-Hold
 >                                   <-Re-Invite*
without SDP*
 > 200 OK --> recv-only
 >                                <Ack with SDP

As already noted, the offerless reinvite doesn't indicate a desire
to go
off hold. Nor does it indicate a desire to stay on hold. Rather, it
asks
the other side to indicate its preference at this time.

The subsequent offer of recvonly is however probably at least an unwise
choice for the left UA. It wasn't the end that initiated the hold, and
so *presumably* it would prefer to *not* be on hold. Assuming that is
the case, it should have send an offer with sendrecv. If it had done
that, then the UA on the right would have been able to choose to answer
sendrecv if it wanted to be off hold

Re: [Sip-implementors] Question on Offer/Answer Model with SIP

[Paul Kyzivat]

Amarnath,

Take a look at RFC6337 for an in-depth treatment of offer/answer issues 
and best practices. More below, consistent with what is in that rfc.


On 12/19/18 12:28 AM, Amarnath Kanchivanam wrote:

Hi,

I have below call flow and would like to know the correct behavior.

UAC  UAS
INVITE ->
 <---200 OK
Ack  -->

Now UAS puts call on Hold

  <---Re-Invite with send-only
attribute
200 OK --> recv-only
<--Ack

Now UAS does Un-Hold
  <-Re-Invite* without SDP*
200 OK --> recv-only
   

Re: [Sip-implementors] Query about Content-Type when Content-Length = 0

[Paul Kyzivat]

On 12/7/18 5:12 AM, Hamza Mohamed Salman wrote:

Dear,

Good Day.

The trace result shows that The 480 arrives to the node, and it is rejected 
(dropped) because there is a fault in the message. The following is seen in the 
communication buffer of the TEST SYSTEM trace we receive yesterday.

SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/UDP 
BC00.RAHBC1.MSS.ALMADAR.NET:5060;branch=z9hG4bK0036926780904874;received=10.150.22.1
Allow: ACK,BYE,CANCEL,INFO,INVITE,MESSAGE,NOTIFY,OPTIONS,PING,REFER,UPDATE
Call-ID: 
{acx8285710251vwbcghefemdm...@bc00.rahbc1.mss.almadar.net
Contact: 
Content-Type: application/sdp
CSeq: 116019009 INVITE
From: 
;tag=13000730723785
Record-Route: 
To: ;tag=1543136248.891036.906647130
User-Agent: swengine v3.5 r16205
Content-Length: 0


While content-type header is present, the content-length is zero, what is not 
acceptable. You can see the explanation below from SIP OPM before, but I copy 
here again
For application/sdp type of body RFC 4566 is applicable, which specifies 
mandatory and optional parts of the body.
In other words, application/sdp body itself is not expected to be empty."

Upto 16A (GSM_MSC  SW), our software was allowing this message, but from 17A 
onward, the software has been updated to adapt 100% to the standard.

Here I also attached the Network Impact Report of 16A to 17A. In page number 
46, this impact on SIP request/response messages are mentioned.
* MSC-S releases call if SIP request/response is received with 
following combination
 of elements (not according to syntax rules):
- A message body part (e.g. SDP) is received, Content-Type header indicating
the body part presence is received and Content-Length header received
indicates zero (0) length of the body part,
- No message body part is received but the Content-Type header indicating
the body part presence is received.

Im asking if we can  change the 480,486 messages and remove content-type header 
or not??


IMO this case isn't clearly addressed in 3261.

But note that there is a "default" content type for the body of sip 
messages, and that default varies based on the type of message. For 
INVITE the default is application/sdp. (I forget if it says, but I think 
the same default can assume to apply the responses to the message.)


So even if you omit a Content-Type, one is implied for every message, 
independent of whether there is a body or not. Hence you should not be 
troubled by having a content-type present in a message with no body.


For SDP, the syntax doesn't itself permit an empty body. But as used in 
SIP, the presence or absence of an SPD body (or body part) is used to 
discern whether an offer/answer is present.


To answer your question directly, you may include or omit the 
'Content-Type:application/sdp/' header field for messages with no body.


Thanks,
Paul

BTW, there *could* be other content types that syntactically permit a 
zero-length body. I suppose in principle that might present a specific 
use for content-type with a missing body - especially when the 
content-type is not the default for the message type. AFAIK this has not 
been tested, and might have a high probability of failing in existing 
implementations.


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

Re: [Sip-implementors] RTP with wrong payload

[Paul Kyzivat]

On 11/15/18 12:02 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

G.722 was offered in the initial INVITE to PBX, but was not accepted by PBX, in 
200OK from PBX there were only G.711A

SDP in INITIAL invite:
SDP PDU
   v=0
   o=BroadWorks 400693062 1 IN IP4 195.54.102.188
   s=-
   c=IN IP4 195.54.102.188
   t=0 0
   m=audio 15148 RTP/AVP 8 110 111 0 96
   b=AS:141
   a=rtpmap:8 PCMA/8000
   a=rtpmap:9 G722/8000
   a=rtpmap:97 AMR/8000
   a=fmtp:97 
mode-set=0,2,4,7;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0
   a=rtpmap:110 AMR/8000
   a=fmtp:110 mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 telephone-event/8000
   a=fmtp:96 0-15
   a=maxptime:20
   a=ptime:20


The above seems a bit odd:

- why is there no rtpmap for 111?

- why is there an rtpmap for 97 that isn't mentioned in the m-line?

And then, the problem you are reporting is that the *offerer* is 
receiving (on port 15148) packets with pt=9?


Thanks,
Paul



SDP in 200OK for INVITE from PBX
SDP PDU
   v=0
   o=- 6613665318425236764 2 IN IP4 172.18.8.21
   s=MX-ONE
   c=IN IP4 172.18.8.32
   t=0 0
   m=audio 30838 RTP/AVP 8 101
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=ptime:20
   a=sqn:0
   a=cdsc:1 image udptl t38
   a=cpar:a=T38FaxVersion:0
   a=cpar:a=T38MaxBitRate:14400
   a=cpar:a=T38FaxRateManagement:transferredTCF
   a=cpar:a=T38FaxMaxBuffer:9772
   a=cpar:a=T38FaxMaxDatagram:1472
   a=cpar:a=T38FaxUdpEC:t38UDPRedundancy
   a=sendrecv

BR/pj

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul 
Kyzivat
Sent: den 15 november 2018 17:37
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RTP with wrong payload

On 11/15/18 1:21 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

I should have given more details, in the example I gave there was actual a 
couple of G.722 packets that was marked with payload type G.722 received in a 
session where G.711A(PCMA/8000) was established as the agreed codec, the 
receiving PBX did not have support for G.722.
As I interpret  RFC 3550 the PBX should drop the G.722 packets and let the 
session continue, and same applies also in case where G.722 is supported by 
PBX,  am I wrong ?


Just to be sure...

Are you saying that G.722 was not negotiated at all? Or that it wasn't the 
first codec in the list?

If multiple codecs are negotiated, then it is permissible to use them, and even 
mix their use. (This is most often a cobmination of telephone-events with 
another codec, but isn't limited to that.

Can you post the actual offer/answer SDP that was used to negotiate the session?

Thanks,
Paul


BR/pj

-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: den 15 november 2018 05:10
To: Paul Heitkemper
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RTP with wrong payload

Paul Heitkemper  writes:

RFC 3550 Section 5.1

" A receiver MUST ignore packets with payload types that it does not
understand."


Though this rule is based on the payload type code, and not the encoding.  The 
original post says only that the packets contain G.722 data, but if that data 
is marked with the payload type code that was negotiated for G.711A, the 
recipient will try to decode it as G.711A.
Perhaps the recipient can determine that the data is invalid (as G.711A) and 
discard it, but more likely it will decode it into some sort of noise which it 
will present to the user.

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



___
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 with wrong payload

[Paul Kyzivat]

On 11/15/18 1:21 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:

I should have given more details, in the example I gave there was actual a 
couple of G.722 packets that was marked with payload type G.722 received in a 
session where G.711A(PCMA/8000) was established as the agreed codec, the 
receiving PBX did not have support for G.722.
As I interpret  RFC 3550 the PBX should drop the G.722 packets and let the 
session continue, and same applies also in case where G.722 is supported by 
PBX,  am I wrong ?


Just to be sure...

Are you saying that G.722 was not negotiated at all? Or that it wasn't 
the first codec in the list?


If multiple codecs are negotiated, then it is permissible to use them, 
and even mix their use. (This is most often a cobmination of 
telephone-events with another codec, but isn't limited to that.


Can you post the actual offer/answer SDP that was used to negotiate the 
session?


Thanks,
Paul


BR/pj

-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: den 15 november 2018 05:10
To: Paul Heitkemper
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RTP with wrong payload

Paul Heitkemper  writes:

RFC 3550 Section 5.1

" A receiver MUST ignore packets with payload types that it does not
understand."


Though this rule is based on the payload type code, and not the encoding.  The 
original post says only that the packets contain G.722 data, but if that data 
is marked with the payload type code that was negotiated for G.711A, the 
recipient will try to decode it as G.711A.
Perhaps the recipient can determine that the data is invalid (as G.711A) and 
discard it, but more likely it will decode it into some sort of noise which it 
will present to the user.

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



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

Re: [Sip-implementors] t.38 port equal 0 in SDP

[Paul Kyzivat]

On 9/15/18 5:32 AM, Qter wrote:

Dear Experts,

I see that one device is sending re-INVITE message with such SDP 
parameters:


v=0
o=- 1092631119 2 IN IP4 10.10.10.100
s=-
c=IN IP4 10.10.10.100
t=0 0
m=image 0 udptl t38
m=audio 29044 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -

The question is if m=image 0 udptl t38 is correct (port number equal 0)?
Is it according to some RFC?


There is nothing wrong with such an offer. An m= line with a zero port 
number is inoperable for this round of offer/answer, because the answer 
must also have a zero port number. It can serve as a place-holder where 
the offerer has plans to use it in a future offer, or hopes you will use 
it in a future offer. I suppose it might be intended as an indicator 
that the offerer is *capable* of supporting that, but AFAIK there is no 
such standardized meaning.


Thanks,
Paul


BR

Bart

---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie 
antywirusowe Avast.

https://www.avast.com/antivirus

___
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] REFER received before ACK, What to do!!

[Paul Kyzivat]

On 9/6/18 1:05 AM, karthik sasupalli wrote:

Hi All,

I have a scenario, where the REFER to an INVITE is received before the ACK.

There is a Desk Phone and a Call server. The call is initiated by the Call
server.

Desk Phone <-- INVITE <-- Call Server
Desk Phone --> 180 Ringing --> Call Server
Desk Phone --> 200 OK/SDP --> Call Server
*Desk Phone <-- REFER <-- Call Server*
Desk Phone <-- ACK/SDP <-- Call Server

The dialogue becomes confirmed when ACK is received. But in this case, the
REFER is received before ACK and hence it is received even before the
dialogue is confirmed.

If, in place of REFER, a RE-INVITE is received (before ACK), then the Desk
Phone should send 491 Request Pending, informing the server that a previous
request is still being processed.

According to RFC3515, the server should retry REFER (in case the response
is any one of the below)

Retry-After 404,413,480,486 o
Retry-After 500,503 o
Retry-After 600,603 o

I have changed the code in Desk Phone, so that, when a REFER is received
before the ACK is received, the Desk Phone responds with 603 Declined.

The server should understand this 603 response and try to resend REFER
after some time so that REFER is received after ACK.

Is my approach okay in terms of RFC compatibility and implementation point
of view?

Please give your views.


Please provide more detail. In particular, the content of the key 
messages, and what the call flow is intending to accomplish.


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

Re: [Sip-implementors] MSRP SEND's CPIM From header - display name in URI

[Paul Kyzivat]

On 9/4/18 1:56 PM, Nancy Greene wrote:

This question came up when we started to look at display name in a CPIM From header of an 
MSRP SEND (RFC4975):  If you put quotes around a display name (called Formal-name in 
RFC3862), then you do NOT put a space after the end quote and the "<" of the 
URI.


From RFC3862, the definition of 
From is:

From-header = "From" ": " [ Formal-name ] "<" URI ">"
 ; "From" is case-sensitive

In the ABNF the definition of Formal-name is:
Formal-name  = 1*( Token SP ) / String
String   = DQUOTE *( Str-char / Escape ) DQUOTE
Token= 1*TOKENCHAR

So, if the Formal-name starts with double quotes (") there is no space (SP) between the last double 
quote and the angle brackets in starting the URI. As such, the values should be: Alice 
   or   "Alice"

This is probably a tiny oversight in RFC3862, but I guess we are not going to 
update the RFC - has anyone come across this before?


I guess we can question whether this is an oversight or intentional. (I 
don't recall, but I would guess an oversight.) There are no examples 
with a quoted Formal-name to confirm the intent.


This was "patterned" after From in SIP, but it diverges in several ways. 
3261 is quite free with whitespace, whereas this is strict about it. 
Also there is the case-sensitivity of "From", if you believe the the 
comment in the ABNF is normative.


I doubt there will be a bis, but you could initiate an update if you 
feel it is important.


I would recommend that implementations strictly follow the syntax in 
what the generate, but be looser in what they accept, around whitespace 
and case-sensitivity.


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

Re: [Sip-implementors] 401 Unauthorized with Require Header?

[Paul Kyzivat]

On 8/16/18 1:21 AM, Sreekanth wrote:

On Thu, 16 Aug 2018 at 08:31, Dale R. Worley  wrote:


Sreekanth  writes:

I am going through the SIP RFC (3261) and couldn't find anything

specified

regarding the 401 Unauthorized challenge response from the UAS side

during

a registration.

I wanted to confirm whether it is okay to add a *Require *header into

this

401 Unauthorized message response.


What would be the point?  The concept of a Require header is "the UAS is
required to reject the request (420) if it doesn't understand the
option-tag".  If a *response* had a Require header, either the UAC
understands the option-tag and processes the response as normal, or it
doesn't understand the option-tag ... and then what does it do?  It
can't send a 420 response *to a response*.

Dale



Dale, I'm trying to add a new feature in the existing REGISTER framework
and the CPE will determine whether or not this new feature should get
activated based on the 401 response from the Registrar server. If the
Registrar server includes the Require header in the 401 response, then the
CPE knows that this feature is supported by the Registrar.


It would helpful for you to lay out the scenario you have in mind for 
this new feature.


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

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

[Paul Kyzivat]

On 7/16/18 1:17 PM, Alex Balashov wrote:

Hi,

I have a scenario where a call is forked through a proxy to an early
media announcement server and then subsequently to a SIP provider for
actual termination.

Due to the way the RTP relay works on the server side, this results in
two different SDP offers from the two respective outgoing branches being
sent back to the caller:

1. 183+SDP on branch #1.

2. 183+SDP' on branch #2.
200 OK+SDP' on branch #2.


These are both sent back to the UAC?

If so, these should arrive with different to-tags, and so will establish 
distinct early dialogs. Those can coexist. Then when the 200 arrives, 
(regardless of which dialog it comes on), the UAC should send a CANCEL 
on the other dialog (to the Contact URI for that dialog. Or it can send 
a BYE.


There is a race condition where you get a 200 on *both* early dialogs. 
In that case you have two separate calls to deal with. Then you can send 
a BYE on one of them, or manage them both separately, or treat them as a 
conference, or whatever you want.


OTOH, if perchance the two 183 responses have the *same* to-tag, then 
you have an error situation.


Thanks,
Paul


I am not sure offhand whether this is a protocol semantics violation. On
the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:

If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE.  For this specification, that is
only the final 2xx response to that INVITE.  That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer.  The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.

So, I always understood that the first answer is the final answer,
absent a session-updating request cycle. On the other hand, RFC 3960
("Early Media and Ringing Tone Generation in the Session Initiation
Protocol (SIP)") Section 4 says:

The application server model consists of having the UAS behave as an
application server to establish early media sessions with the UAC.
The UAC indicates support for the early-session disposition type
(defined in [2]) using the early-session option tag.  This way, UASs
know that they can keep offer/answer exchanges for early media
(early-session disposition type) separate from regular media (session
disposition type).

I take this, along with RFC 3959 Section 3, to imply an amendment to
3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
will handle this situation.

Any insight would be appreciated!



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

Re: [Sip-implementors] RFC 6337, Section 5.3. Hold and Resume of Media

[Paul Kyzivat]

Parveen,

On 7/10/18 4:24 AM, Parveen Aggarwal wrote:

Hi Experts,

I have below scenario

1. A Calls B with "sendrecv"
2. B holds call with "sendonly"
3. A holds call with "inactive"-- both A and B media direction is "
*inactive" *now

Now, If B receives re-invite without SDP what should be media direction
attribute value
"*sendonly"* or *"inactive" *in offer of 200OK

*As per RFC 6337, Section 5.3. Hold and Resume of Media*

If a UA has occasion to send another offer in the session, without
any desire to change the hold status (e.g., in response to a re-
INVITE without an offer, or when sending a re-INVITE to refresh the
session timer), it should follow the "General Principle for
Constructing Offers and Answers" (Section 5.1). * If it previously*
*   initiated a "hold" by sending "a=sendonly" attribute or "a=inactive"*
*   attribute, then it should offer that again*.  If it had not previously
initiated "hold", then it should offer "a=sendrecv" attribute, even
if it had previously been forced to answer something else.  Without
this behavior it is possible to get "stuck on hold" in some cases,
especially when a 3pcc is involved.


The issue above is that when A held the call, it probably should not 
have offered "inactive". Assuming it just wanted a normal hold and was 
willing to offer music on hold, then it should have used "sendonly" in 
its offer. In response, B would then probably have answered "inactive", 
because it didn't want to receive media.


Then the above text you highlighted would work right.

The key principle is that the end generating an *offer* should offer 
what *it* desires, without trying to guess what the other end wants. 
Then the answerer generates an answer that is compatible with the offer 
and otherwise reflects what the answerer wants.


Trying to guess what the other end wants often gets you into trouble, 
because it unnecessarily limits what the answer can do. In your example, 
when A offers "inactive" rather than "sendonly" then it is (probably) 
doing so because it is *assuming* that B doesn't want to receive media.


However this depends on the implementation. A device that doesn't want 
to send music on hold may indeed want to offer "inactive" to initiate a 
hold.


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 422 and RFC 4028

[Paul Kyzivat]

On 7/3/18 10:34 AM, Alex Balashov wrote:

Yeah, that's true.

It's easily forgot in an applied sense because the mainstream FOSS proxies, 
e.g. Kamailio, both support dialog state tracking and issuing various kinds of 
in-dialog DPD requests (e.g. OPTIONS), and even support spoofing BYEs to hang 
up a dead call if DPD requests go unreplied.

But of course, that's radioactively non-standards-compliant. :-)


I don't know if they are compliant or not. To do the things you 
describe, they must actually be B2BUAs. (E.g., they must rewrite all the 
sequence numbers.) So they need to be judged on whether they are 
compliant as UAs, not as proxies.


Thanks,
Paul


On July 3, 2018 10:20:41 AM EDT, Paul Kyzivat  wrote:

On 7/3/18 3:53 AM, Alex Balashov wrote:

No, it's not illegal to retry a call to the same gateway (in case of

6xx response).


Nor is it illegal to reject it. :-)

My experience in an applied sense with SSTs (SIP Session Timers) is

that they are poorly supported, seemingly due to all the state-keeping
involved. Many UAs commit to a refresher role, for instance, but don't
actually issue the reinvites to refresh.


Instead, it is a more commonplace to approach to just use

nullary-change reinvites for signalling-level DPD (dead peer
detection), without the baggage of SSTs. So for instance, there are a
lot of carriers out there whose equipment will just send you a reinvite
every 15 minutes to check if you're alive, quite regardless of any
SSTs, roles, support for SSTs, etc.

I think people forget that UAs have no need of session timers, since
they can do as you say, whenever they wonder about the status of the
session.

The real point of session timers is in support of proxies in the
signaling path. If they want to keep session state, then they have no
way to know when to clear that state if they see no signaling for a
long
time. The session timers give them a way to ask the UAs to help them
out.

More in another reply.

Thanks,
Paul



-- Alex

--
Sent via mobile, please forgive typos and brevity.
___
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 422 and RFC 4028

[Paul Kyzivat]

On 7/3/18 6:15 AM, Aman wrote:

I find out an interesting conversation exactly about my scenario, when RFC
4028 was a draft and was in discussion mode,
https://www.ietf.org/mail-archive/web/sip/current/msg00743.html

Call flow:
UAC - P-A - P-B -- UAS

1. UAC sends a simple INVITE w/o any session timer. 2. P-A inserts
Session-Expires: 600 3. P-B detects that this value is too small and
generates a 422 Session Timer too small Session-Expires: 900 4. P-A
forwards this up the UAC The INVITE transaction has completed so P-A clears
all state (there was no call established). 5. The UAC receives 422 Response
but does not understand it. Hence, the 422 defaults to 400 class response;
no retry with different timer value is done.


Did UAC include Supported:timer in the invite?
If not, it may well not implement session timer at all, and so can't be 
expected to understand the 422.



So what I understood is the proposed solution is to have the proxy(P-A)
insert a Min-SE header in this case.

Question is, if proxy P-A does the same, is it mandatory or not for UAC to
retry the INVITE with suggested session-expire value even if the response
code is 4XX.


No, it isn't. For one, as noted above, it may not support s-t at all.
Even if it does, it might not wish a call with a larger value. (But that 
is implausible in this case, since it expressed no desire for a s-t at all.


*If* UAC does support s-t, then this behavior indicates a poor 
implementation, yet it is still a conforming implementation.


Thanks,
Paul


Thanks,
Amanpreet Singh.


On Tue, Jul 3, 2018 at 1:24 PM Alex Balashov 
wrote:


No, it's not illegal to retry a call to the same gateway (in case of 6xx
response).

Nor is it illegal to reject it. :-)

My experience in an applied sense with SSTs (SIP Session Timers) is that
they are poorly supported, seemingly due to all the state-keeping involved.
Many UAs commit to a refresher role, for instance, but don't actually issue
the reinvites to refresh.

Instead, it is a more commonplace to approach to just use nullary-change
reinvites for signalling-level DPD (dead peer detection), without the
baggage of SSTs. So for instance, there are a lot of carriers out there
whose equipment will just send you a reinvite every 15 minutes to check if
you're alive, quite regardless of any SSTs, roles, support for SSTs, etc.

-- Alex

--
Sent via mobile, please forgive typos and brevity.
___
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 422 and RFC 4028

[Paul Kyzivat]

On 7/3/18 3:53 AM, Alex Balashov wrote:

No, it's not illegal to retry a call to the same gateway (in case of 6xx 
response).

Nor is it illegal to reject it. :-)

My experience in an applied sense with SSTs (SIP Session Timers) is that they 
are poorly supported, seemingly due to all the state-keeping involved. Many UAs 
commit to a refresher role, for instance, but don't actually issue the 
reinvites to refresh.

Instead, it is a more commonplace to approach to just use nullary-change 
reinvites for signalling-level DPD (dead peer detection), without the baggage 
of SSTs. So for instance, there are a lot of carriers out there whose equipment 
will just send you a reinvite every 15 minutes to check if you're alive, quite 
regardless of any SSTs, roles, support for SSTs, etc.


I think people forget that UAs have no need of session timers, since 
they can do as you say, whenever they wonder about the status of the 
session.


The real point of session timers is in support of proxies in the 
signaling path. If they want to keep session state, then they have no 
way to know when to clear that state if they see no signaling for a long 
time. The session timers give them a way to ask the UAs to help them out.


More in another reply.

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

Re: [Sip-implementors] Media Port change during Hold/resume

[Paul Kyzivat]

On 6/8/18 11:29 AM, Parveen Aggarwal wrote:

Dear Experts,

I am facing one scenario:

1. Make video call: Audio and video port non-zero
2. downgrade video call: audio port non-zero and video port 0
3. Network hold the call: audio:sendonly , video port 0
4. network sending re-invite without SDP, User agent sending offer in 200
OK but with video port 0
5. Network sending ACK with audio: sendonly, video port: 0
===
after this Network is resuming the call with re-invite but at the same time
it is sending video port as non-zero.

Is it a correct behavior to update audio media direction from recvonly to
sendrecv and updating the Video port in same re-INVITE? (Any spec reference)


I don't see anything particularly wrong in anything above, to the extent 
that I understand what you mean.


It isn't clear to me who initiated the downgrade to audio only. If that 
was the network, rather than the caller, and if the caller still desires 
video, then in (4) I would expect it to offer a non-zero video port 
again. But there is a lot of local discretion in that.


It isn't clear to me what it is that you are questioning.

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

Re: [Sip-implementors] Call failure after ReInvite

[Paul Kyzivat]

On 5/23/18 1:34 PM, Abhishek wrote:

Hello Paul,
Thank you very much for response.

We could see with some of the peer nodes that Call is continuing even if ACK 
message does not carry SDP.


Behavior after a protocol violation is undefined, so if they want to try 
to go forward in that case they can. But the state of the session is 
undefined in that case.


Thanks,
Paul


Best Regards,
Abhishek Phadke


On 23-May-2018, at 22:38, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:

Abhishek,


On 5/23/18 7:15 AM, Abhishek wrote:
Hello,

SS7 Switch —> Gateway Switch —> SIP SBC

Call flow is as mentioned.

SIP call gets established between Gateway Switch node and SIP SBC node.

  
Gateway Switch node initiates Re Invite without SDP.


SIP SBC node responds with 200 OK along with SDP keeping all fields same as 
previous 200 OK including ‘sess-version’ field.

Gateway Switch node acknowledge this message with ACK without SDP.

SIP SBC node sends BYE to this response and mentions Reason as cause=488, No 
answer to offer.

  
Would like to understand way forward for resolution of this issue.


While the details are sketchy, IIUC then the Gateway Switch is clearly in error 
- it is required to include answer SDP in the 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] Call failure after ReInvite

[Paul Kyzivat]

Abhishek,

On 5/23/18 7:15 AM, Abhishek wrote:

Hello,


SS7 Switch —> Gateway Switch —> SIP SBC

Call flow is as mentioned.

SIP call gets established between Gateway Switch node and SIP SBC node.

  


Gateway Switch node initiates Re Invite without SDP.

SIP SBC node responds with 200 OK along with SDP keeping all fields same as 
previous 200 OK including ‘sess-version’ field.

Gateway Switch node acknowledge this message with ACK without SDP.

SIP SBC node sends BYE to this response and mentions Reason as cause=488, No 
answer to offer.

  


Would like to understand way forward for resolution of this issue.


While the details are sketchy, IIUC then the Gateway Switch is clearly 
in error - it is required to include answer SDP in the 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] To tag in 407 challenges

[Paul Kyzivat]

On 3/25/18 7:06 PM, Alex Balashov wrote:

My perplexion is rooted precisely in the fact that no dialog has been 
established upon a negative final reply to the invite transaction.


While I agree that logically the to-tag is in some cases unnecessary in 
cases like this, the fact is that 3261 requires that the tag be present. 
It would make no sense to try to change that at this late time. So the 
UAS should simply do as it is required to do - generate a tag and put it 
in the response.


Thanks,
Paul


On March 25, 2018 6:27:03 PM EDT, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:

On 3/25/18 5:26 PM, Alex Balashov wrote:

Hi,

Are 407 challenges meant to have a To tag? If so, I can't find the
rationale in 3261. Any pointers would be appreciated.


(working from memory)

An argument against to-tag in 407 would presumably apply equally to any

3xx, 4xx, 5xx, or 6xx. One could argue that the to-tag is for
establishing a dialog, and if no dialog has been established then it
isn't needed.

OTOH, AFAIK the requirement to include a to-tag is across the board.

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



-- Alex

--
Sent via mobile, please forgive typos and brevity.
___
Sip-implementors mailing list
Sip-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 in 407 challenges

[Paul Kyzivat]

On 3/25/18 5:26 PM, Alex Balashov wrote:

Hi,

Are 407 challenges meant to have a To tag? If so, I can't find the
rationale in 3261. Any pointers would be appreciated.


(working from memory)

An argument against to-tag in 407 would presumably apply equally to any 
3xx, 4xx, 5xx, or 6xx. One could argue that the to-tag is for 
establishing a dialog, and if no dialog has been established then it 
isn't needed.


OTOH, AFAIK the requirement to include a to-tag is across the board.

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

Re: [Sip-implementors] Codec Negotiation issue

[Paul Kyzivat]

On 2/22/18 3:34 AM, Rakesh wrote:

Hi Expert,

I have a scenario here can anyone help me to undrstand is the behaviour is
correct on both cases?

FIRST CASE:
• User A calls User B
• Negoziation for EVS codec
• User A put in hold User B
• REINVITE from User A, contains sendonly, with only EVS (codec negotiated
and used).
• REINVITE arrives to User B, it contains sendonly with all the codecs
handled by volte network in the following order: EVS, AMR WB, AMR NB.
• User B answer with 200 OK just with EVS and the call has not any call
quality issue.

SECOND CASE:
• User B put in Hold User A
• User B sends REINVITE with sendonly containing only EVS,
• REINVITE arrives to User A with sendonly and it contains all the VoLTE
codecsin the following order: AMR WB, EVS, AMR NB.
• User A answer with 200 OK recvonly that contains only AMR-WB because is
the first in the list and the call quality has degraded

So is the codec negotiation in both cases OK I am asking since in one case
call quality is OK and in other case call quality is NOK?

Any RFC standard or reference  to understand completely the codec order and
priority to handle?


In general, if the UA offers some codecs, those are the ones it is 
prepared to use. A proxy is not permitted to alter those. If it did, it 
would risk a situation where the codec selected in the answer isn't 
supported by the offerer.


I gather that this is an IMS case, and that the middle box that is 
altering the offer is a B2BUA. In that case it takes on the 
responsibility of making things right between the two sides of the call. 
When it adds codecs, that implies that it is prepared to transcode 
between them if necessary. And I presume that is what must happen in the 
second case.


This sort of behavior isn't covered by any standards. Hardly any 
behavior of B2BUAs is covered by standards, except that the B2BUA must 
follow the rules for a UA independently on each "side".


The result you see is a consequence of what the middle box did, and can 
be considered a quality of implementation issue. It may be exactly what 
was intended.


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

Re: [Sip-implementors] 200 OK Retransmission

[Paul Kyzivat]

On 1/3/18 7:54 PM, onewhoknows wrote:

Hello,

I have an issue with some older releases of Asterisk talking to an Avaya
PBX.

I think there's a network issue somewhere, but in the meantime, I'd like to
know which side is handling the following transaction correctly:

Asterisk > Avaya
Invite >
< 100 Trying
< 200 OK

ACK

< 200 OK
< 200 OK
< 200 OK
... several more times
< 200 OK
< BYE

200 OK


The issue is intermittent and when it occurs, the far end does not see the
ACK.

My question in this particular instance is should Asterisk be responding to
each 200 OK with an ACK, or has it satisfied its part of the transaction by
sending that first ACK?  Each 200 OK has the same CSEQ, branch, etc.


Asterisk is wrong. The ACK must be transmitted for each 200 OK received.

This is necessary in the case where an ACK is lost. The UAS is 
retransmitting the 200 because it hasn't yet received an ACK.


You say this is intermittent, which is consistent with an ACK being lost.

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

Re: [Sip-implementors] Different TO Tag in SIP Bye as compare to SIP 200 OK

[Paul Kyzivat]

On 11/29/17 9:50 PM, NK wrote:

Dear All,

I have the problem where the customer is sending the BYE after 200 OK, but
my switch refused to identify the dialog and sent the SIP 481, and I feel
this is because of different TO tag.

SIP 200 OK in the correspondence of initial Invite.

*Switch to UAC*

From: "" ;tag=6H3KeXvvcFDQg
To: ;tag=*gK09c21acd*

*UAC to Switch*

From: "" ;tag=6H3KeXvvcFDQg
To: ;tag=*v5kVTeFILvVHE8nhSC71RxPENPrbcwAq*


Please say more what you mean by "switch", and provide more detail: 
preferably all the messages from the INVITE to the BYE.


Trying to guess from what you have above, I infer that the client (UAC) 
is +122, and is calling 0 that is handled by the 
"switch" (UAS). And the message containing the first From/To is from the 
200 OK to an INVITE from the client, and then the 2nd From/To is from a 
BYE sent by the client.


If so, and nothing else funny is going on then I agree that the client 
is messing up by including the wrong to-tag.


Thanks,
Paul


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

Re: [Sip-implementors] Changing in "o=" field

[Paul Kyzivat]

On 11/20/17 5:27 AM, wisniawy wrote:

Hello
My Application Server sends a re-INVITE to the called party pointing in the SDP 
a Media Server instead of calling party IP address (included in original 
INVITE).
  
INVITE:

o=BroadWorks 204147 1 IN IP4 10.8.91.9
  
re-INVITE:

o=BroadWorks 204150 1 IN IP4 10.8.92.133
  
The re-INVITE is dropped by Mobile Switching Station (MSS) because the session-version ("1") of the new SDP offer is identical to the previous one.

My question is if the MSS behaviour is correct?
In my oppinion, as the  has changed, the session should be 
treated as a new one not as a modification of the old one.


The new offer is incorrect based on the following text from RFC3264:

   When issuing an offer that modifies the session,
   the "o=" line of the new SDP MUST be identical to that in the
   previous SDP, except that the version in the origin field MUST
   increment by one from the previous SDP.  If the version in the origin
   line does not increment, the SDP MUST be identical to the SDP with
   that version number.

Exactly what the recipient should do when this is violated is undefined. 
IIUC it is pretty typical to ignore the violation. But an implementation 
is justified in refusing it.


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/ACK race

[Paul Kyzivat]

On 10/31/17 8:44 AM, Liviu Chircu wrote:

Hi Alex,

IMO, building logic into the proxy which encourages/mends the proper 
sequencing of UDP messages does nothing more than to hide the underlying 
problem, i.e. "UDP does not guarantee message sequencing in the first 
place" *. There is also a subtle point to be made here: your proxy's 
loosely coupled/parallelized way of handling the two transactions is 
effectively breaking the RFC some % of the time, since the proxy's TU is 
generating a new INVITE while another INVITE transaction is in progress 
(strictly judging by the network timestamps).


One can argue that the proxy is doing nothing wrong and perhaps being 
helpful by exposing bugs in handling of reordered UDP messages.


Thanks,
Paul

* From this angle, the only sane thing left to do is to have the proxy 
retry the re-INVITE for UASs who are properly responding with 491 and 
propagate any other 4xx/5xx error replies back to the UAC (UA B in our 
case) in the hope that they retry their re-INVITE.


Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 30.10.2017 19:11, Alex Balashov wrote:

Hi,

I've got a scenario like so:

    UA A -> Proxy P > UA B

1. UA A initiates call through Proxy P;

2. Dialog is established and confirmed, with Record-Route;

3. UA B sends reinvite #1 through P to A;

4. UA B sends 2xx reply;

5. UA B sends end-to-end ACK for reinvite #1 and almost
    simultaneously sends reinvite #2. The temporal delta is
    between reinvite #2 and ACK for reinvite #1 on the wire
    is 3 ms.

The issue is that the concurrency characteristics of proxy P are such
that its worker threads are very loosely coupled, and there's no
synchronisation among them for message ordering. Transport is UDP,
naturally.

So, the result — for all kinds of stochastic processing and userspace
scheduling type reasons — is that the reinvite is forwarded first,
before the ACK.  That leads to a 500 / 491 scenario UA A.

Is there any general guidance on what to do with these scenarios? I
looked at RFC 5407 § 3.1.4, which appears to describe a similar, but not
identical scenario involving an initial INVITE and subsequent reinvite.
As far as I can tell, the recommendation in that standard is "space the
messaging out more in time".

Switching to TCP would presumably help, since any given flow would
involve a single connection to a single worker thread and the transport
would guarantee ordering. However, that's not really feasible in this
implementation for a host of reasons.

Any other thoughts welcome!

Cheers,

-- Alex



___
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-NOTIFY method for CNAM querying

[Paul Kyzivat]

(disclaimer: while I know quite a bit about SIP I know nothing about 
these CNAM query mechanisms. AFAIK none of these mechanisms are covered 
by IETF standards.)


On 10/30/17 1:25 AM, Alex Balashov wrote:

Hello,

I apologise for cross-posting this from VoiceOps, and concede that it is
an applied and operational question as much as it is a formal one.
Nevertheless, any help would be appreciated.

As far as I know, SIP redirects are the generally accepted transport for
generic data queries (e.g. LRN dips, CNAM) over SIP.


Can you provide a reference to a specification for how this is done?


However, there is
another method, which is used by Metaswitch, Sansay, and possibly some
other softswitch vendors: the SUBSCRIBE-NOTIFY method
This is one in which an ephemeral presence subscription (i.e. with an
Expires: value of 0) is created by the querying switch, and the CNAM
gateway returns a NOTIFY some time later containing the CNAM data reply
some time later in its body. The most complete explanation, including
some limited insight into design rationales, is available from Neustar,
who offer this query method:

https://www.neustar.biz/resources/cnam/data-services-lidb-user-guide.pdf

See Chapter 7 - IP-CNAM Speification (page 25).


It looks like Neustar is acting as a quasi-standard for this mechanism.

Unfortunately I find no formal registration of this event package in the 
IANA Event Types registry, so it is a rogue definition and thus using it 
is a spec violation.



This is a weird and, in my opinion, ill-conceived mechanism[1][2].
Nevertheless, it is widely implemented.

What I can't seem to figure out is where the formal definition of the
standard comes from. It's certainly not an IETF RFC. The Metaswitch CFS
provides a hint:

MetaSphere CFS and Metaswitch MGC support performing Caller Name Database
(CNAM) lookups by sending SUBSCRIBE messages to a database server, and
receiving NOTIFYs containing the caller name.

The specification of this interface is non-Metaswitch proprietary
information. However, example message flows are shown in A.4.16.

Whose proprietary information?


Based on your own reference, looks like it is Neustar's.


I found this Verizon patent:

https://www.google.com/patents/US20080240383

But it appears to be concerned with an adaptation layer of this to the
ISCP side, though I only skimmed it. And if this is the patent in
question, why don't any footnotes in vendor docs refer to it? The
footnotes cite the SIP event pub-sub framework (RFC 3265) and little
else.

What the heck is it? And why did it get to be preferred over redirects
for some vendors, especially given that it invokes — but ultimately
foregoes — most of the bureaucracy of the event subscription mechanism,
in a way that's seemingly contradictory.

-- Alex
  
[1] For one, it uses attributes in the encapsulated payload which look like

headers, but aren't headers:

Calling-Name-Status: available
Calling-Name: “Joe Smith” 
Presentation-Indicator: allowed

Why bother with an encapsulated body, then?


This isn't my definition so I can only speculate, but there is need for 
*some* syntax for the payload. This is the syntax that was chosen. If 
you already have a SIP parser, then it should be easy to write a parser 
for this too. If *you* were defining the event package then you might 
make a different choice.


If you are asking why not just use these as SIP headers in the NOTIFY, 
then the answer is that they aren't SIP headers, and you could never get 
them approved as such.



[2] More objectively, a SUBSCRIBE creates a dialog. But if the lifetime
of the subscription is zero (expires immediately), presumably the dialog
it creates also ends immediately. Why, then, does the NOTIFY have to be
structured as an in-dialog NOTIFY (i.e. same From/To tags as the
SUBSCRIBE)?


That is just the way the event mechanism is defined. It is a degenerate 
form of a subscription with a longer expiration, and hence follows all 
the same rules. Defining different rules would have just make 
implementations more difficult.


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

Re: [Sip-implementors] Codec negotiation on SIP Referred-by

[Paul Kyzivat]

Hi Ivo,

On 10/10/17 5:26 PM, Ivo Vastert wrote:

Hi Paul,

What we try to do is the following scenario:

Inbound call from: #gateway1 ==> #SBC1 ==> SIP client (Gateway offers 
G711alaw, G711ulaw and G729) SBC passes codecs as-is.

Sip client has codec preference (G722, G729, G711alaw, G711ulaw)
The SIP client accepts this call, (#Leg1, on G729)

Then the SIP client makes a outbound call: SIP client ==> #SBC1 ==> 
#gateway2

Sip client has still codec preference (G722, G729, G711alaw, G711ulaw).
#Gateway2 has codec preference (G722, G711alaw, G729).
#Gateway2 accepts this call on G722.

So now we have the following situation:
A SIP client with 2 legs, both going to #SBC1, where #Leg1 is on G729 
and #Leg2 on G722.


The SIP client sends a SIP REFERED-by to #SBC1 to connect the legs to 
each other.


I guess you mean it sends a REFER request addressed to gateway1, with a 
Refer-To URI referencing gateway2. Do I have that right? That will go 
through SBC1.


Now, does the SBC intercept this and handle it via 3pcc? or does it 
allow the REFER to continue to the gateway?


The *natural* thing to do is let gateway1 handle it. In that case, the 
gateway will generate a new INVITE. It should load the offer up with 
whatever codecs it has - presumably the same as before (G711alaw, 
G711ulaw and G729). When that reaches gateway2 it will presumably choose 
G711alaw.


If the SBC attempts to instead handle this via 3pcc, and wants to have a 
chance to make this work, then it should do so by sending an offerless 
re-invite to gateway1. Then gateway1 should respond as above. This can 
then be sent as an offer to gateway2 and things should work out as in 
the natural case.


If the SBC attempts to do 3pcc but tries to construct an offer for the 
re-invite then it needs to be careful or it will mess things up. This is 
*hard*.


Thanks,
Paul

In this case there is a codec mismatch, but currently our SBC is still 
bridging the calls which results in bad audio because of a codec mismatch.


What should be the behaviour of the SBC / B2BUA in this case?

Br,

Ivo

On Tue, Oct 10, 2017 at 8:37 PM, Paul Kyzivat <pkyzi...@alum.mit.edu 
<mailto:pkyzi...@alum.mit.edu>> wrote:


On 10/10/17 12:33 PM, Ivo Vastert wrote:

Hi,

I have a question regarding possible codec re-negotiation in a
Referred-by
scenario.
We have the following situation:

A UA which has 2 legs open to a SBC / B2BUA.
1 Leg is on G729 and 1 Leg on G722.

The UA is sending a Referred by towards the SBC to bridge the 2
calls.
What should happen with the codec negotiation in this case since
there is a
mismatch?


Can you provide more detail on what is going on here? I can't follow
from the above description. In general, when sending an offer you
are well advised to offer all the codecs you are able to support, to
maximize the possibility of finding an optimal choice for both ends.

         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
<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] Codec negotiation on SIP Referred-by

[Paul Kyzivat]

On 10/10/17 12:33 PM, Ivo Vastert wrote:

Hi,

I have a question regarding possible codec re-negotiation in a Referred-by
scenario.
We have the following situation:

A UA which has 2 legs open to a SBC / B2BUA.
1 Leg is on G729 and 1 Leg on G722.

The UA is sending a Referred by towards the SBC to bridge the 2 calls.
What should happen with the codec negotiation in this case since there is a
mismatch?


Can you provide more detail on what is going on here? I can't follow 
from the above description. In general, when sending an offer you are 
well advised to offer all the codecs you are able to support, to 
maximize the possibility of finding an optimal choice for both ends.


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

Re: [Sip-implementors] Network Initiated De-registration

[Paul Kyzivat]

On 10/6/17 10:29 PM, Dale R. Worley wrote:

Paul Kyzivat <pkyzi...@alum.mit.edu> writes:

On 10/6/17 1:04 PM, Abhishek Jain wrote:

1. Under what senarios or conditions, Network would initiate deregistration
to a UE ?


The only reason that is covered by ietf sip standards is expiration of
the registration without renewal. Other reasons would be based on
policy. For instance, if the account for the AoR has beed deleted.


Thinking about it, I don't think that there's a general way for the
network to signal to the UA (UE) that it has been prematurely
deregistered, that is, deregistered before the expiration of a
previously granted registration.  Of course, once the proxy/registrar
isn't willing to route calls to the UA, it *is* deregistered, and of
course, it can refuse to accept calls originating from the UA.


The "reg" event package (RFC3680) can be used to discover that you have 
been deregistered.


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

Re: [Sip-implementors] B2BUA behavior in correlation of Pre-Conditions & Multiple Early Dialogs

[Paul Kyzivat]

On 10/6/17 2:42 PM, VARUN BHATIA wrote:

Hello,

As a B2BUA what is the expectation when it is sitting behind a forking
proxy (IMS Application Server) and it is sending back multiple early
dialogs back.

1. It should ideally send it back transparently to ingress i.e.
creating multiple early dialogs at ingress leg too. (UAC should be
capable of supporting early dialogs)


IMO this is the straightforward thing to do.


2. Doing inter-working with ingress and rather than sending multiple
early dialog toward ingress it should send new offer in UPDATE.
(Though in this case UAC should support UPDATE method in early
dialog).


I realize (sadly) that there may be some UAs that don't properly handle 
multiple early dialogs, and some B2BUAs may want to make them work by 
handling the complications for them. OTOH, doing anything other that (1) 
is tricky. The guiding rule is that the B2BUA must follow all the rules 
for a UAS on the ingress side and (independently) for a UAC on the 
egress side. There really aren't any other rules. Be as creative as you 
like.



In the above scenario if Pre-condition is been expected then will
there be any change or it should be same.
As per my understanding forking proxy should handle, in this scenario,
once the pre-condition has been exchanged & resource reservation has
been done. AS should not send multiple early dialog towards B2BUA.


Preconditions could make this very difficult to do.


Though i am trying to find reference in RFC or 3GPP standard but not
yet able to find any.


I'm not at all up to date on what in in 3GPP standards. But frankly I 
would be very surprised to find anything.


Thanks,
Paul


Your expert inputs are much appreciated and if it can be provided in
some reference to standard it will be very helpful.




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

Re: [Sip-implementors] Network Initiated De-registration

[Paul Kyzivat]

On 10/6/17 1:04 PM, Abhishek Jain wrote:

Hi,

1. Under what senarios or conditions, Network would initiate deregistration
to a UE ?


The only reason that is covered by ietf sip standards is expiration of 
the registration without renewal. Other reasons would be based on 
policy. For instance, if the account for the AoR has beed deleted.


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

Re: [Sip-implementors] rules for From-tag generation in forking B2BUA

[Paul Kyzivat]

On 10/4/17 4:20 PM, Andrew Pogrebennyk wrote:

Hi,
I understand that there is no normative document for a B2BUA but in
general as common sense dictates should the B2BUAs that generate
multiple outgoing requests on their UAC side for a single incoming
request due to parallel forking create unique From-tags or reuse the
same From tag in every request (INVITE)? I have concerns over a SBC
vendor that requires same From tag (else some overload prevention kicks
in) because it looks like re-using From-tag (but having different Via
branches of course) might trigger a loop detected response with some
endpoints as per https://tools.ietf.org/html/rfc3261#section-8.2.2.2
What is the best practice here?


ISTM that if the B2BUA is intending to act mostly like a forking proxy, 
then it would make the most sense for it to generate a single new 
from-tag for itself corresponding 1:1 with the incoming from-tag on its 
UAS side and then use that for all outgoing forks. But that is 
technically a violation of UAC behavior, so I can see why some 
implementations might not do 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] 183 session

[Paul Kyzivat]

On 9/19/17 11:28 AM, Verma, Salil (Nokia - IN/Noida) wrote:

Hi ,

Please help me to understand the difference between 183 with SDP and without 
SDP.


A 183 without SDP has no role in the offer/answer process. It mostly 
just says "I'm working on your call." In the absence of the 100rel 
option it has no other significance. If it also has 100rel then it 
establishes an early dialog.



Is it really required to send 183 after invite r we can directly send 180 
ringing ? In which all condition we have to send 183


If you want to send 180 to indicate that you are alerting then there is 
no reason to also send 183. Just as with 183, the 180 may be sent with 
or without SDP.


Note that the decision about whether to play early media at the UAC is 
not determined by the reception of a 183. Rather it is governed by the 
reception of media at the port in your offer, and can in principle occur 
even without receiving a 18x of any sort. However some implementations 
refuse to play early media until they receive an answer with an IP and 
port that they use to verify the sender of the media. If you are doing 
such validation, then it shouldn't matter what sort of 18x it is.


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

Re: [Sip-implementors] SBC sending 403 Forbidden when UE includes Anonymous in From header's user part

[Paul Kyzivat]

On 9/19/17 6:39 AM, Abinash Sarangi wrote:

Hi Experts,

We are facing an issue wherein INVITE sent by UE is being rejected by SBC with 
403 Forbidden


This is a *policy* issue rather than a *protocol* issue.
The response indicates that the callee (or the SBC acting on behalf of 
the callee) has a *policy* leading it to reject the call.


In this case it seems likely that it doesn't want to accept calls where 
the caller is unknown. In environments that use PAI, the expectation is 
that calls will have a known verified caller identity. There may still 
be provision (Via Privacy and an anonymous From) to hide that identity 
from the callee, but the infrastructure insists on knowing.


If you want to place calls in this environment then you have to abide by 
the rules of identification put in place by the network. Again, this 
isn't a protocol issue.


Thanks,
Paul


INVITE snap

INVITE sip:0655430...@xyz.net;transport=TLS SIP/2.0
Via: SIP/2.0/TLS a.b.c.d:37789;branch=z9hG4bK-n5o538-e-125n6m9;rport
Max-Forwards: 70
To: 
From: Anonymous ;tag=n5o538-xwco1g
Call-ID: n5o538-1hjm5to-9@90-237-255-147
CSeq: 14 INVITE
Contact: 
Content-Type: application/sdp
Content-Length: 429
User-Agent: ABC 1.6.3 a

User itself is sending anonymous value in FROM header with no Privacy header 
and without P-Preferred-Identity


In IMS network, CLI information is extracted from PAI and if no PAI is present 
same information can be retrieved from “From” header.


From RFC 3261 point of view,


The From header field allows for a display name.  A UAC SHOULD use
the display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
identity of the client is to remain hidden.

Question : should the UE also send Privacy header with appropriate values ?

Is the SBC behavior appropriate in rejecting the INVITE ?


Network deployment:

UE--> SBC--> IMS core --> MTAS



Thanks
AS
___
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] Offerless Re-INVITE

[Paul Kyzivat]

Rakesh,

See comments below.

On 9/7/17 11:43 AM, Rakesh wrote:

*Hi ,*



*Can any one tell me what will be the codec can be sent on 200OK in below ?*


*Is this the one that support by UE or the Supported codec by Proxy ?*


*UA Proxy
*>>*   ->
*>>*  (INVITE SDP: codecs 0 18 101)
**  <--
*>>* (200 OK SDP: codecs 0 101)
**   >
*>>* ACK  (no SDP)
*>>*  <---
*>>*  (re-INVITE no SDP)
** -->
*>>

*  (200 OK SDP: codecs ?)*



*As per RFC,**RFC 6337 section 5.2.5:
*>>* "When the new offer is sent in response to an offerless (re-)INVITE, it
*>* should be constructed according to the General Principle for Constructing
*>* Offers and Answers (Section 5.1 ): all codecs the UA is currently willing
*>* and able to use should be included, not just the ones that were negotiated
*>* by previous offer/answer exchanges.  The same is true for media types --
*>* so if UA A initially offered audio and video to UA B, and they end up with
*>* only audio, and UA B sends an offerless (re-)INVITE to UA A, A's resulting
*>* offer should most likely re-attempt video, by reusing the zeroed "m=" line
*>

* used previously."*

*SO I didn't able to understand this "*


*all codecs the UA is currently willing

and able to use should be included, not just the ones that were negotiated
by previous offer/answer exchanges."*


What don't you understand?

In the above scenario from 6337, the most likely behavior would be for B 
to include whatever it would normally include in an initial offer in a 
new call. But this has to be tempered a bit by the constraints that 
apply to subsequent offers in a dialog.


The verbiage about "currently willing and able to use" is to acknowledge 
ability and willingness to use particular media may vary with time and 
be based on interaction with the user of the device. When responding to 
an initial invite the UAS can delay generating the offer or answer while 
alerting, and the UI might give the user ability to indicate if he wants 
to use video, etc. But in the offerless reinvite case there isn't any 
opportunity to do that, so the UAS must decide what to include based on 
policy. In the case of a video phone with a dedicated display and camera 
it may be safe to always include video. But if the UAS is a computer 
with a camera that is shared by many applications, if the camera isn't 
already assigned to the phone app then video probably can't be used in 
the offer.


In your initial example, the callee (B) initially accepted the codecs 
associated with PTs 0 and 101, so I would expect that at a minimum those 
would be included. Presumably B doesn't support codec 18, so that 
wouldn't be included in the new offer. If there are any *other* codecs 
that it does support it could include them in the new offer too. (B 
*could* have also included those in its initial answer, but that doesn't 
seem to be a common behavior.)


I assume your example is only audio. If B also supports video, and is 
willing to start using it mid-call it could also include that in the new 
offer.


Thanks,
Paul

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

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

[Paul Kyzivat]

Robert,

I agree with most of what you say, but have a comment on one point:

On 8/1/17 12:23 PM, Robert Sparks wrote:
Be sure you are aware of (and implementing) the updates to RFC3261. You 
really need RFC6026 to answer this question cleanly.


At the top level, this is far enough into "things are violating 
protocol" that the specs aren't going to give algorithmic advice.


The closest they will get is that the transaction would pass the 200 to 
the transaction user (and then it would sit in the Accepted state until 
timer M fires so it can pass any _other_ 200s that show up with the same 
transaction identifier up to the TU - See figure 3 and the text above it 
in RFC6026).


Consider a case where the original INVITE was parallel forked. One of 
the forks behaves in this broken way and is the first to respond. Now 
the state machine is in the Accepted state. In that state 1xx and 
3xx-6xx responses are (IIUC) ignored. All *may* turn out if one of those 
other forks eventually returns a 2xx. Otherwise the call will just time 
out. Proper handling of the non-2xx final responses from the other forks 
won't occur. And if the 1xx was needed (e.g. for preconditions) then 
that won't work either.


Just dropping the broken 2xx would give better results. But I don't find 
any text that justifies doing that in this case.


Thanks,
Paul

Now, at the TU level, the 200 that shows up will not match any 
outstanding potential dialog (in some code-bases, you'll see these 
called proto-dialogs). The specs don't say this explicitly (as far as I 
recall anyhow), but the logic would follow something like this: "This 
doesn't match any INVITE _I've_ sent - it's an unsolicited response, I'm 
dropping it".


You might be tempted to try to ack on the 200, to at least stop the 
retransmissions (and maybe stop any media that might be flowing from the 
other end). If you do that, you could do whatever you do for any other 
unsolicited 200 that just shows up. But in this case, those attempts are 
likely to fail, and may make recovering from the mess worse, rather than 
better. Assuming you don't have a malicious actor, and what happened was 
that some B2BUAish thing changed the call-id in the request, but not the 
response, then the ACK you send (remember that 200-ACKs are sent with a 
new transaction identifier because they may take a different path than 
the INVITES) is likely to also get changed. If you send the ACK with the 
dialog identifiers from the INVITE, you _might_ get lucky and get the 
same transformation out of the thing in the middle, but given the 
different transaction ID, I suspect not. If you send the ACK with the 
dialog identifiers from the 200, they're almost certainly going to be 
changed before they get to the other side and the ACK won't be 
recognized. So letting the TU just drop the 200 is the safest thing to 
do in general.


Now, if you're in cohoots with the thing that's breaking the protocol, 
you know enough about its behavior to work around its brokenness, but 
then you're inventing some other protocol for a specific deployment and 
the specs can't help you.


RjS

On 8/1/17 11:03 AM, Paul Kyzivat wrote:

On 7/31/17 11:49 PM, Prakash K wrote:

Hi Paul,

Thanks a lot,  You have put it in a nice way , I understood the 
use-case for Forking


But I have the following question

*This all assumes that the 2xx matches an INVITE transaction you have 
pending, and that the from-tag and call-id match what was in the 
corresponding INVITE.Otherwise this is a stray message or an attack 
and ought to be ignored.*


*So if the 200 OK received having different "Call-ID" *not matching 
with the Call-ID which is sent in INVITE by UA, it should be ignored. 
( even if Cseq/From-tag/branch parameter is same as INVITE which is 
sent out)  ?*


What would be the UA behaviour in above case ?


This is an interesting case. 3261 doesn't provide a lot of explicit 
guidance - the proper action needs to be teased out of the text.


My first reaction was that you should just drop this message. But I 
couldn't find a good justification for that.


My next thought was that if it qualifies as a valid response to the 
*transaction* then the transaction should be run to completion. 
Following the revised state machine in rfc6026 that means moving to 
the Accepted state (if not already in that state), and passing the 2xx 
to the TU for further processing. Then the TU would discover that this 
response is messed up because it doesn't match an existing dialog, and 
also doesn't match a pending dialog (same from-tag and callid). As a 
result, it probably shouldn't send an ACK.


But this troubles me because it moves the state machine to the 
Accepted state. Thus is prevents subsequently received 1xx,3xx-6xx 
responses from being properly handled.


I think just dropping this response would lead to a better result, but 
I can't quite see how to justify that action from 3261 and 6026.

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

[Paul Kyzivat]

On 7/31/17 11:49 PM, Prakash K wrote:

Hi Paul,

Thanks a lot,  You have put it in a nice way , I understood the use-case 
for Forking


But I have the following question

*This all assumes that the 2xx matches an INVITE transaction you have 
pending, and that the from-tag and call-id match what was in the 
corresponding INVITE.Otherwise this is a stray message or an attack and 
ought to be ignored.*


*So if the 200 OK received having different "Call-ID" *not matching with 
the Call-ID which is sent in INVITE by UA, it should be ignored. ( even 
if Cseq/From-tag/branch parameter is same as INVITE which is sent out)  ?*


What would be the UA behaviour in above case ?


This is an interesting case. 3261 doesn't provide a lot of explicit 
guidance - the proper action needs to be teased out of the text.


My first reaction was that you should just drop this message. But I 
couldn't find a good justification for that.


My next thought was that if it qualifies as a valid response to the 
*transaction* then the transaction should be run to completion. 
Following the revised state machine in rfc6026 that means moving to the 
Accepted state (if not already in that state), and passing the 2xx to 
the TU for further processing. Then the TU would discover that this 
response is messed up because it doesn't match an existing dialog, and 
also doesn't match a pending dialog (same from-tag and callid). As a 
result, it probably shouldn't send an ACK.


But this troubles me because it moves the state machine to the Accepted 
state. Thus is prevents subsequently received 1xx,3xx-6xx responses from 
being properly handled.


I think just dropping this response would lead to a better result, but I 
can't quite see how to justify that action from 3261 and 6026.


I'd like to hear from others who are knowledgeable about such things.

Thanks,
Paul


On 31 Jul 2017 10:21 p.m., "Paul Kyzivat" <pkyzi...@alum.mit.edu 
<mailto:pkyzi...@alum.mit.edu>> wrote:


On 7/31/17 11:26 AM, Prakash K wrote:

What would be the behavior of UA when 200 OK received which is
not matching
the dialog

"200OK received by UA with different Call-id which is not in
context"


I see the following snippet in RFC 3261 which says UA should create
dialog. Wont this end up in acknowledging the hacking?

If the dialog identifier in the 2xx response matches the dialog
 identifier of an existing dialog, the dialog MUST be
transitioned to
 the "confirmed" state, and the route set for the dialog MUST be
 recomputed based on the 2xx response using the procedures
of Section
 12.2.1.2.  *Otherwise, a new dialog in the "confirmed"
state MUST be
 constructed using the procedures of Section 12.1.2.*


does this mean UA should generate ACK & immediately followed by
BYE should
be triggered?


As is mentioned in the prior paragraph, this is primarily about
forking. If the initial INVITE is forked, then two or more UASs may
respond. Each will choose a unique to-tag, and since the to-tag is
part of the dialog-id each will be associated with a distinct dialog.

The dialogs for various forks may be discovered via 1xx responses,
in which case the corresponding 2xx may match an existing dialog.
OTOH sometimes a UAS will send a 2xx without first sending a 1xx. In
that case the mentioned situation will occur.

Also note that this can happen without forking if the single UAS
immediately responds with a 2xx.

The forking case where you actually get multiple 2xx reponses,
establishing multiple dialogs, is pretty rare. Usually the forking
proxy ceases forking when it sees a 2xx response and attempts to
cancel any other outstanding legs. But it *can* happen and the UAC
needs to be prepared to cope when it does. *What* you do is
unspecified. Immediately sending a BYE is a popular solution because
it is easy. But it isn't especially friendly to the callee. Other
possibilities:

- form a conference call within your UAC, mixing the audio from
   the multiple legs

- play some prerecorded audio explaining why you are hanging up,
   then BYE.

This all assumes that the 2xx matches an INVITE transaction you have
pending, and that the from-tag and call-id match what was in the
corresponding INVITE. Otherwise this is a stray message or an attack
and ought to be ignored.

 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
<https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors&g

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

[Paul Kyzivat]

On 7/31/17 11:26 AM, Prakash K wrote:

What would be the behavior of UA when 200 OK received which is not matching
the dialog

"200OK received by UA with different Call-id which is not in context"


I see the following snippet in RFC 3261 which says UA should create
dialog. Wont this end up in acknowledging the hacking?

   If the dialog identifier in the 2xx response matches the dialog
identifier of an existing dialog, the dialog MUST be transitioned to
the "confirmed" state, and the route set for the dialog MUST be
recomputed based on the 2xx response using the procedures of Section
12.2.1.2.  *Otherwise, a new dialog in the "confirmed" state MUST be
constructed using the procedures of Section 12.1.2.*


does this mean UA should generate ACK & immediately followed by BYE should
be triggered?


As is mentioned in the prior paragraph, this is primarily about forking. 
If the initial INVITE is forked, then two or more UASs may respond. Each 
will choose a unique to-tag, and since the to-tag is part of the 
dialog-id each will be associated with a distinct dialog.


The dialogs for various forks may be discovered via 1xx responses, in 
which case the corresponding 2xx may match an existing dialog. OTOH 
sometimes a UAS will send a 2xx without first sending a 1xx. In that 
case the mentioned situation will occur.


Also note that this can happen without forking if the single UAS 
immediately responds with a 2xx.


The forking case where you actually get multiple 2xx reponses, 
establishing multiple dialogs, is pretty rare. Usually the forking proxy 
ceases forking when it sees a 2xx response and attempts to cancel any 
other outstanding legs. But it *can* happen and the UAC needs to be 
prepared to cope when it does. *What* you do is unspecified. Immediately 
sending a BYE is a popular solution because it is easy. But it isn't 
especially friendly to the callee. Other possibilities:


- form a conference call within your UAC, mixing the audio from
  the multiple legs

- play some prerecorded audio explaining why you are hanging up,
  then BYE.

This all assumes that the 2xx matches an INVITE transaction you have 
pending, and that the from-tag and call-id match what was in the 
corresponding INVITE. Otherwise this is a stray message or an attack and 
ought to be ignored.


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

Re: [Sip-implementors] Contact header URI comaprision

[Paul Kyzivat]

On 7/18/17 4:00 AM, Rakesh wrote:

Hi Paul,

Thanks for the update.

So the 200OK in step 4 Registrar  should respond with only one contact 
header
Contact: ""<sip:+168999@178.21.49.29 
<mailto:sip%3A%2B1689998@178.21.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=-;srti=s1_2>;expires=7200 
?


Yes.

But since there is a difference in contact so it has to be overwritten 
with the previous contact of step1?


I don't understand what you are trying to say with this last sentence.

In my earlier reply I quoted the wrong section of 3261. (It was the 
section for clients, not registrars.) The applicable portion is from 
steps 7&8 of section 10.3:


 7.  ...
 For each address, the registrar then searches the list of
 current bindings using the URI comparison rules.  If the
 binding does not exist, it is tentatively added.  If the
 binding does exist, the registrar checks the Call-ID value.  If
 the Call-ID value in the existing binding differs from the
 Call-ID value in the request, the binding MUST be removed if
 the expiration time is zero and updated otherwise.  If they are
 the same, the registrar compares the CSeq value.  If the value
 is higher than that of the existing binding, it MUST update or
 remove the binding as above.  If not, the update MUST be
 aborted and the request fails.
 ...

  8. The registrar returns a 200 (OK) response.  The response MUST
 contain Contact header field values enumerating all current
 bindings. ...

Hence it is clear that new contact value must be recorded by the 
registrar and returned in the response.



Currently, the Registrar is working in the below way,

Contact: 
""<sip:+168999@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=0


Contact: 
""<sip:+168999@178.21.49.29:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=-;srti=s1_2>;expires=7200


Since the both the contact are same as per 19.1.4 it is only keeping the 
contact header value of the second REGISTER request.


Again I don't understand your point. The response enumerate all 
*current* bindings. Because it is returning two URIs it must think that 
they are both current. Yet they compare equal so the registrar should 
have replaced the old one with the new one, and hence there should only 
be one current contact - the new one.


Thanks,
Paul


Can you please clarify?

BR///

Rakesh Kumar Mohanty


On Mon, Jul 17, 2017 at 10:13 PM, Paul Kyzivat <pkyzi...@alum.mit.edu 
<mailto:pkyzi...@alum.mit.edu>> wrote:


On 7/17/17 11:08 AM, Rakesh wrote:

Hi Expert,

Now I got the full picture for the problem.

SIP Registrar  behavior for the URI contact matching

1) REGISTER request with belwo contact send to Registrar

Contact: ""<sip:+168999@178.21.49.29

<mailto:sip%3A%2B168999@178.21.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=7200

2) Registrar sent 200OK with below contact

Contact: ""<sip:+168999
​​
@178.21.49.29

<mailto:sip%3A%2B168999@178.21.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=7200

3) Now there is another REGISTER request send to the Registrar
in contact with additional parameter mentioned below

Contact: ""<sip:+168999@178.21.49.29

<mailto:sip%3A%2B1689998@178.21.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=-;srti=s1_2>;expires=7200

4) Then Registrar sent 200OK response with below contact
headers. Where the Initial contact has value expires= 0

Contact: ""<sip:+168999
​​
@178.21.49.29

<mailto:sip%3A%2B168999@178.21.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;srti=s1_2>;expires=0

Contact: ""<sip:+168999@178.21.49.29

<mailto:sip%3A%2B1689998@178.21.49.29>:3694;transport=udp;Hpt=8ea2_16;ssn;TRC=-;srti=s1_2>;expires=7200


So is it a valid behavior from Registrar server? Which leads the
earlier post asked for contact matching.


 >From 3261:

10.2.4 Refreshing Bindings

Each UA is responsible for refreshing the bindings that it has
previously established.  A UA SHOULD NOT refresh bindings set up by
other UAs.

The 200 (OK) response from the registrar contains a list of Contact
fields enumerating all current bindings.  The UA compares each
contact address to see if it created the contact address, using
comparison rules in Section 19.1.4.  If so, it updates the
expiration
time interval according to the expires parameter or, if absent, the
Expires field value.  The UA then issues a REGISTER request fo

Re: [Sip-implementors] Contact header URI comaprision

[Paul Kyzivat]

On 7/17/17 11:08 AM, Rakesh wrote:

Hi Expert,

Now I got the full picture for the problem.

SIP Registrar  behavior for the URI contact matching

1) REGISTER request with belwo contact send to Registrar

Contact: 
"";expires=7200


2) Registrar sent 200OK with below contact

Contact: 
"";expires=7200


3) Now there is another REGISTER request send to the Registrar in 
contact with additional parameter mentioned below


Contact: 
"";expires=7200


4) Then Registrar sent 200OK response with below contact headers. Where 
the Initial contact has value expires= 0


Contact: 
"";expires=0


Contact: 
"";expires=7200



So is it a valid behavior from Registrar server? Which leads the earlier 
post asked for contact matching.


From 3261:

10.2.4 Refreshing Bindings

   Each UA is responsible for refreshing the bindings that it has
   previously established.  A UA SHOULD NOT refresh bindings set up by
   other UAs.

   The 200 (OK) response from the registrar contains a list of Contact
   fields enumerating all current bindings.  The UA compares each
   contact address to see if it created the contact address, using
   comparison rules in Section 19.1.4.  If so, it updates the expiration
   time interval according to the expires parameter or, if absent, the
   Expires field value.  The UA then issues a REGISTER request for each
   of its bindings before the expiration interval has elapsed.  It MAY
   combine several updates into one REGISTER request.

   A UA SHOULD use the same Call-ID for all registrations during a
   single boot cycle.  Registration refreshes SHOULD be sent to the same
   network address as the original registration, unless redirected.

We have already discussed those comparison rules. So the second REGISTER 
should qualify as a refresh. But apparently the registrar is not 
recognizing it as such and instead is treating it as an additional 
registration. That appears to be a bug in the registrar.


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

Re: [Sip-implementors] Contact header URI comaprision

[Paul Kyzivat]

On 7/14/17 3:53 AM, Rakesh wrote:

Hi Expert,

I am facing an issue on which the contact URI comparison has happened 
and it fails due to the TRC parameter not in order which I guess so far.


Contact: "" 

Contact: "" 



I saw in RFC 3261 19.1.4 URI Comparison

URI uri-parameter components are compared as follows:


...

The following:


  -  All other uri-parameters appearing in only one URI are
 ignored when comparing the URIs.


is the operative rule here.

So does it mean the correct order should be given below where the TRC 
parameter should be put at the last?


Contact: "" 

Contact: "" 



What leads you to this conclusion? Parameter order is never relevant.

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

Re: [Sip-implementors] SDP answer with c=0.0.0.0 and a=sendrecv behavior

[Paul Kyzivat]

Comment at end

On 7/7/17 11:17 AM, Sourav Dhar Chaudhuri wrote:

Hi,

There is a B2B sitting between  A (Caller) and B ( callee)


1) A  has sent INVITE without SDP towards B

2)B has responded  200OK with SDP offer for INVITE to  A. Refer 
below the SDP offer


v=0
o=- 16408314 16408314 IN IP4 ABC.DEF.GH.IJ
s=-
c=IN IP4 192.168.119.69
t=0 0
a=sendrecv
m=audio 3866 RTP/AVP 8 0 18 96
c=IN IP4 192.168.119.69
b=RR:0
b=RS:0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=maxptime:40



3)Then A has sent ACK with SDP answer.

v=0
o=- 8 1 IN IP4 192.168.95.142
s=-
c=IN IP4 0.0.0.0
t=0 0
a=sendrecv
m=audio 24208 RTP/AVP 8 0 96
c=IN IP4 0.0.0.0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=maxptime:40

Now this ACK is not passed to B by the B2B sitting between them.
Is the SDP answer is valid? As it can be seen in connection line 0.0.0.0 
but media attribute is sendrecv. Is sendrecv possible here?




There is another successful  case

1) A  has sent INVITE without SDP towards B

2) B has responded  200OK with SDP offer for INVITE to  A. Refer 
below the SDP offer


v=0
o=- 1498048404 1498048404 IN IP4 192.168.95.97
s=Basic Session
c=IN IP4 192.168.95.97
t=0 0
m=audio 22780 RTP/AVP 18 8 0 96 99
a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1
a=rtpmap:99 telephone-event/8000
a=ptime:20

3)Then A has sent ACK with SDP answer.

v=0
o=- 2 1 IN IP4 192.168.95.142
s=Basic Session
c=IN IP4 0.0.0.0
t=0 0
m=audio 23148 RTP/AVP 8 0 99
a=rtpmap:99 telephone-event/8000
a=ptime:20

  This time the  ACK is passed successfully to B by the B2B sitting 
between them. Here it can be seen in SDP answer that connection line is 
0.0.0.0 but no sendrecv.


What is your theory here? Is it that the B2BUA is objecting to sendrecv 
with 0.0.0.0, yet is ok when no directionality is specified? (But where 
the default is still sendrecv.)


I don't offhand see anything objectionable about either of these. ISTM 
that the B2BUA is being overly picky. And in any case, even if it finds 
something wrong, just dropping the ACK is not realistic way of dealing 
with it.


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

Re: [Sip-implementors] Is it possible to fork early media?

[Paul Kyzivat]

On 7/5/17 10:18 PM, Dale R. Worley wrote:


In a perfect world, the caller would test each media stream for whether
it is "silent", and then all of those that are not silent would be mixed
for presentation to the user.  (Humans can usually parse multiple audio
sources.)  If an early dialog receives a 18x response but there is no
media stream that can be matched with that callee, it may be valuable
for the calling UA to include an appropriate audio signal in the mix --
a ringing tone for a 180, a forwarding tone for a 181, etc.


In a perfect world the UAC would also try to distinguish in band 
ringback from other "more interesting" audio. Mixing multiple ringbacks 
is likely to just make a mess, and mixing ringback with voice also isn't 
ideal.


My impression is that in practice this doesn't happen enough to expend 
much effort on optimizing it.


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

Re: [Sip-implementors] Is it possible to fork early media?

[Paul Kyzivat]

On 7/4/17 12:55 PM, Rodrigo Pimenta Carvalho wrote:



Hi.

I still have to study and learn about forking calls via SIP.
But, before starting my studies, I would like to know if it is possible to do 
fork + early media.

For example,  when user U1 calls and his call is forked (parallel fork) to 
users U2 e U3, if there is early media negotiation between the caller and the 
callees, can U1 keep the media stream with U2 and U3 simultaneously?

If it is not possible to keep such early media streams, is it a matter of SIP  
capacity ?


It's *possible* - it could happen. It just depends on how the 
alternative forks behave. It is up to the caller to decide how to cope 
in this case. The first step is to realize it can happen (that seems to 
be where you are) and then decide on a strategy to deal with it.


You could try to mix the streams for playout to your caller. But that is 
a bother and is unlikely to provide a good user experience. Or you can 
play out one stream and ignore the others. Of course you would like to 
play out the one that is going to answer first, but you don't know which 
one that is. If you guess right then you will have a good user 
experience. If you guess wrong then things will seem odd to the user 
when you eventually switch to the stream from the answerer. That will 
require you to start playing out a stream you had been ignoring - you 
need to figure out when to do that. It won't necessarily be obvious from 
the answer sdp which stream that is.


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

Re: [Sip-implementors] Sending deRegister request just after sending REGISTER request

[Paul Kyzivat]

On 6/28/17 1:11 AM, Parveen Aggarwal wrote:

Dear Expert,

Is it valid to send deRegister request i.e. REGISTER with expires=0 before
receiving final response for previous registration request i.e. REGISTER
with expires >0  ?

As per RFC 3261,
It is mentioned for new REGISTER request only

UAs MUST NOT send a new registration (that is, containing new Contact
header field values, as opposed to a retransmission) until they have
received a final response from the registrar for the previous one or
the previous REGISTER request has timed out.


I see no particular reason why this should be considered an error. 
However it might not be wise. It would be possible for the two requests 
to get reordered, so that the unregister is processed before the 
register. Both would appear to succeed, but the end state of the 
registrar would be different.


Another consideration is whether these are done using the same Call-ID. 
(In the same pseudo-dialog.) I don't think it will generally make any 
difference, but it may present issues if you are also requesting a 
temporary gruu with the registration.


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

Re: [Sip-implementors] Handling of message cross over between 200OK(INVITE) and 200OK(PRACK)

[Paul Kyzivat]

Dinoop,

On 5/26/17 4:50 AM, Dinoop wrote:

Thanks Worley and Paul,

My scenario is,

  UAC  B2BUA UaB

   | 1:INVITE(SDP)  ||

   +--->||

   | 2:100[INV]   ||

   |<---+|

   || 3:INVITE(SDP)  |

   |+--->|

   ||   4:D1.183[INV](SDP)   |

   | |<---+

   | 5:D1.183[INV](SDP)   ||

   |<---+|

   |   6:D1.PRACK   ||

   +--->||

   ||   7:D1.PRACK   |

   | +--->|

   ||   8:D1.200[INV](SDP)   |

   | |<---+

   || 9:D1.200[PRA]  |

   | |<---+


Where the 200[INVITE] has reached B2BUA before 200[PRACK]. What should 
be the behavior of B2BUA as Ua-Client on right side. Or in general what 
handling should be done at Ua-client side when this occurs?. Is there 
any standard defined to handle this message crossing?


I don't see any particular issue here. The response to the PRACK is 
required to complete its transaction, but the 200 to the INVITE is 
evidence that the PRACK had been received and that its 200 will be 
forthcoming. You can simply forward the 200 (INV) and the 200 (PRA) as 
they are received, or you could synthesize and send a 200 for the PRACK 
before forwarding the 200 (INV). Or you *could* hold the 200 (INV) until 
you get the 200 (PRA) and reorder them if you wish, though in some 
extreme cases that might lead to timing issues.


Thanks,
Paul

On 25 May 2017 at 23:43, Dale R. Worley > wrote:


Dinoop > writes:
> How can a B2BUA handle message crossing of 200OK(invite) over 
200OK(PRACK)?
> Is it a correct approach  for the implementation to reject the
> 200OK(INVITE) until it receives PRACK response?
>
> I have gone through the RFC 6337, unfortunately nothing is mentioned about
> this scenario.

As Paul says, the B2BUA has to behave correctly "on each side".  In your
situation, we would need to see a detailed diagram of the message flow
you are contemplating before we would know exactly what the situation is
and what possible strategies the B2BUA could use.




--
Thanks & Regards
Dinoop p



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

Re: [Sip-implementors] Handling of message cross over between 200OK(INVITE) and 200OK(PRACK)

[Paul Kyzivat]

On 5/24/17 2:53 AM, Dinoop wrote:

Hi,

How can a B2BUA handle message crossing of 200OK(invite) over 200OK(PRACK)?
Is it a correct approach  for the implementation to reject the
200OK(INVITE) until it receives PRACK response?

I have gone through the RFC 6337, unfortunately nothing is mentioned about
this scenario.


The fundamental rule to keep in mind for B2BUAs is that each "leg" must 
obey the UA rules. The logic you use to bridge the two legs is up to you.


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

Re: [Sip-implementors] Duplicate RTP streams with same source IP address and Port number

[Paul Kyzivat]

Ramesh,

On 5/22/17 3:00 PM, Ramesh Kuppili wrote:

SIP Gurus,

I have a situation where I am receiving multiple RTP stream from the
same IP address and port number.  But with different SSRC. The media in
the both streams is the same (audio, more precisely ringback tone).  How
should I handle this scenario.

1. Should I accept one stream and ignore the other.  If so, which stream
should I prefer.

2. Should I mix both the streams and play on the endpoint.  I am almost
certain that mixing both the audio streams will result in undesirable
ringback like tone.

Is there a any standard that specifies how I should handle this case.
Any pointers in this regard is really appreciated.


I'm not an expert in media processing, but I'll try to provide some context.

First can you confirm that you are talking about media associated with a 
single 5-tuple negotiated via a single m-line in SDP?


Historically SIP didn't talk about this. In the primary usage for simple 
VOIP I think the expectation has been that only a single RTP stream will 
used at any one time. But that stream may change over time. (For 
instance when transitioning from in-band ringback to media from the 
callee.) So I think it has been fairly typical to simply play out what 
is received without regard to SSRC.


However more advanced uses of SIP have used multiple SSRCs. There was 
never any formal prohibition against doing this, but because there was 
no standardization about how it should be processed there have been no 
guarantees of interoperable behavior when doing so.


Some of the other people who post here can probably give you better 
advice on how best to cope when receiving from multiple SSRCs.


More recently there has been explicit work to standardize such usage. In 
particular:


https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-38

This results in using multiple m-lines, each describing an RTP stream 
but all sharing the same 5-tuple. Presumably that isn't your case.


Thanks,
Paul

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

Re: [Sip-implementors] race_condition

[Paul Kyzivat]

On 4/4/17 1:28 PM, Brett Tate wrote:

Please help to understand situation described as " Race Condition"  !


See RFC 5407.


And if that doesn't give you the answer, then please explain your 
problem in some detail.


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 SIP REGISTER refresh dialog

[Paul Kyzivat]

On 3/10/17 2:49 PM, Dale R. Worley wrote:

Puneet Kumar  writes:

If a UA uses different dialog-ID(say new Call-ID & No To header tag)
for REGISTER refresh with same contact address then it is allowed?
If not then please point out RFC section which blocks a UA from doing it.

In general does REGISTER refresh & REGISTER for deregistration MUST be
in same dialog as earlier REGISTER?


To echo Brett, the sequence of REGISTERs sent by a UAC don't form a
dialog.  (You might consider each individual REGISTER a seperate dialog
containing only one request.)  But since they have the same Call-Id and
increasing CSeq's, they form a series that in some ways resembles a
dialog, that can be called a quasi-dialog or pseudo-dialog.

To understand what a UAC should do and the exact effect of a set of
REGISTERs, you have to study exactly how RFC 3261 section 10 specifies
that REGISTERs are processed by the registrar.  And if the "SIP
Outbound" extension is being used, RFC 5626.


Also, note that the "dialog" nature of registers becomes important for 
the lifetime of temporary GRUUs. (RFC5627)


Thanks,
Paul

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

Re: [Sip-implementors] RFC 7463: PUBLISH with To tag question

[Paul Kyzivat]

On 1/19/17 12:05 PM, Brett Tate wrote:

Hi,

Some of the PUBLISH examples within RFC 7463 (sections 11.7, 11.9, 11.10,
and 11.14) contain a To tag.

Was that was intentional?

RFC 3903 does allow PUBLISH to be sent within dialog.  However, I'm not
sure what within RFC 7463 is actually creating the dialog that is being
shared unless maybe sharing dialog with depicted NOTIFYs (and according to
section 11.7 example, that is not occurring).


Hmm. Sounds like a bug to me.

Thanks,
Paul

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