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

[Sundbaum Per-Johan (Telenor Sverige AB)]

Thank you !


Sensitivity: Internal
-Original Message-
From: Paul Kyzivat 
Sent: den 7 september 2023 16:14
To: Roman Shpount ; Sundbaum Per-Johan (Telenor Sverige AB) 

Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Call hold with a=inactive

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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>> ts.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors=05%7C
>> 01%7Cper-johan.sundbaum%40telenor.se%7Cdebdac44d3204dcd048408dbafacc1
>> 5b%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C638296928738731121%7C
>> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
>> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=JcRfckQoJZLZVbJeHRy%2FCqTcD
>> fgRk07OPIpTpqyZxm8%3D=0
>>
>>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors=05%7C01
> %7Cper-johan.sundbaum%40telenor.se%7Cdebdac44d3204dcd048408dbafacc15b%
> 7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C638296928738731121%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C=JcRfckQoJZLZVbJeHRy%2FCqTcDfgRk07
> OPIpTpqyZxm8%3D=0

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

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

[Sundbaum Per-Johan (Telenor Sverige AB)]

That sounds reasonable, thank you !




Sensitivity: Internal

From: Roman Shpount 
Sent: den 7 september 2023 14:45
To: Sundbaum Per-Johan (Telenor Sverige AB) 
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Call hold with a=inactive

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.
_
Roman Shpount


On Thu, Sep 7, 2023 at 8:38 AM Sundbaum Per-Johan (Telenor Sverige AB) 
mailto: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 mailto:ro...@telurix.com>>
Sent: den 7 september 2023 14:26
To: Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>>
Cc: 
sip-implementors@lists.cs.columbia.edu<mailto: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) 
mailto: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<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] Call hold with a=inactive

[Sundbaum Per-Johan (Telenor Sverige AB)]

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

[Sip-implementors] Call hold with a=inactive

[Sundbaum Per-Johan (Telenor Sverige AB)]

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] Timer

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi !
I would appreciate some help on determine if it's Ok to send UPDATE as in 
picture below.
To me it seems strange sending an UPDATE when a 200OK on initial INVITE would 
have done the job in a more straight forward way, but I can't see any explicit 
statement in RFC4028 that say that you can't use UPDATE in this manner.
Left side is an Oracle SBC and right side is a Cisco CUBE/CM

[cid:image002.png@01D75A52.D1E43110]

BR/pj



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

Re: [Sip-implementors] 400 BadRequest

[Sundbaum Per-Johan (Telenor Sverige AB)]

Thanks, I value your opinion very much !
BR/pj


Sensitivity: Internal

-Original Message-
From: Paul Kyzivat  
Sent: den 23 februari 2021 20:05
To: Sundbaum Per-Johan (Telenor Sverige AB) ; 
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 400 BadRequest

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=p65541t1611061049m518
> 776c21142s1_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=z9hG4bK41638c83800fcb7a519a2b35198b6d9dk5
> 5yacabaaa3Zqkv7ad0qlnsabaaiaqacqaa
> Via: SIP/2.0/TCP 10.49.247.89:5160;branch=z9hG4bK1637070684-451807432
> Route: 
> Record-Route: 
>  ms.mnc008.mcc240.3gppnetwork@scscf2.ims2.se.telenor.net:5060;maddr
> =10.49.247.85;lr>
> 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-g
> enerated-at=pmp6.pcscf2.ims2.se.telenor.net;orig-ioi=ims2.se.telenor.n
> et
> User-Agent: Ericsson MTAS - CXP2010134/1 R19C12
> P-Charging-Function-Addresses: 
> ccf="aaa://europolitan.se";ccf="aaa://riga.europolitan.se"
> Diversion: 
> "46x";reason=unkno
> wn;counter=4;answered-count=1;diversion-inhibited
> Diversion: 
> "46x";reason=unkno
> wn;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 th

Re: [Sip-implementors] 400 BadRequest

[Sundbaum Per-Johan (Telenor Sverige AB)]

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)

-
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 3GPP 24.229.
> 2.21.1.1.1   INVITE Received with SDP 
> Offer<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcalstore.internal.ericsson.com%2Felex%3Fid%3D8956%26ORPA%3Dpreco%26SR%3DTOPIC%26

[Sip-implementors] 400 BadRequest

[Sundbaum Per-Johan (Telenor Sverige AB)]

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  ?

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

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi !

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  ?

"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

Re: [Sip-implementors] reuse of payload type

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi !
Usually its's a normal release Reason: SIP;cause=200;text="User Triggered"
BR/pj

From: Ranjit Avasarala 
Sent: den 5 februari 2021 16:49
To: Arun Tagare 
Cc: Sundbaum Per-Johan (Telenor Sverige AB) ; 
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] reuse of payload type

no it won't, as issue with codecs mismatch and not full/partial offer.  Either 
of them have to change their codec / PT mapping

Just curious,  does BYE have the reason for call termination?

Regards
Ranjit

On Thu, Feb 4, 2021 at 11:13 PM Arun Tagare 
mailto:arun.taga...@gmail.com>> wrote:
Hi All,

Will it solve if you send FULL offer when UE receive re-Invite w/o SDP

pCSCF - VoLTE-phone

INVITE ->

With SDP offer

 <- 180 Ringing

 <- 200OK with SDP answer

ACK ->

re-INVITE ->

without SDP

 <- 200OK with SDP Offer  <<<<<< Here instead of sending
negotiated offer try sending full offer

ACK ->

With SDP answer





On Mon, Jan 25, 2021 at 7:12 PM Sundbaum Per-Johan (Telenor Sverige AB) <
per-johan.sundb...@telenor.se<mailto:per-johan.sundb...@telenor.se>> wrote:

> Hi again !
>
> I just realized that I didn't answer your question
>
> "It looks like there is an attempt to match on PT 108 with AMR/8000. But
> the codec parameters don't match. Is the expectation that they will be
> matched by PT and then will attempt to interwork the differing codec
> parameters?"
>
> I'm not sure, but I will  dig some more on the issue !
>
> BR/pj
>
>
> Sensitivity: Internal
>
> -----Original Message-
> From: Paul Kyzivat mailto:pkyzi...@alum.mit.edu>>
> Sent: den 22 januari 2021 23:44
> To: Sundbaum Per-Johan (Telenor Sverige AB) 
> mailto:per-johan.sundb...@telenor.se>>;
> Ranjit Avasarala mailto:ranjitka...@gmail.com>>;
> 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 12:34 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
> > Hi !
> > My tool is exporting the trace as requested, but it seems the resulting
> .pcap is not decoded so that one is not to any use.
> > I have attached a HTML-version that I hope is at least a little better
> than my text.
>
> That was fine.
>
> Now to analyze this trace...
>
> Note that IIUC the matching between offer and answer is done by codec name
> (from rtpmap) and codec parameters (from fmtp. IIUC the individual
> parameters in the fmtp need to be matched. The order that they are written
> is irrelevant.)
>
> (Not by payload type, which can differ on the two ends, though people like
> it better when it doesn't. But in this case it turns out that the PTs do
> all match between a given offer and answer.)
>
> In the first O/A, there is a match between PT 108 on both ends (AMR/8000,
> max-red=0;mode-change-capability=2;mode-change-neighbor=1;mode-change-period=2;mode-set=7).
>
> I imagine PT 116 in the answer is intended to match 116 in the offer.
> But it technically doesn't because they don't have matching fmpt values.
> I'm guessing it was treated as a match.
>
> In the 2nd O/A, treating it independently of the first one, there are
> matches on 100, 102, 104, 105, 109.
>
> Then question you are asking is about the compatibility of Answer#2 and
> Offer#1. The only match I find is for telephone-event between PT 116 in the
> first answer and PT 100 in the second offer. I think that is what you were
> concerned about. IMO *that* is conforming, since the phone uses
> 116 in both its first answer and its subsequent offer.
>
> It looks like there is an attempt to match on PT 108 with AMR/8000. But
> the codec parameters don't match. Is the expectation that they will be
> matched by PT and then will attempt to interwork the differing codec
> parameters? I don't think that is how it is supposed to work. But this
> isn't really my area - I know the signaling but not the codec manipulation.
>
> I find the following violations where a UA uses a PT for different
> codec/parameters between the first and 2nd Invites:
>
> pCSCF: 100, 102, 108
> phone: 108
>
> Thanks,
> Paul
>
>
>
> > [cid:image001.png@01D6F0ED.27F177E0]
> >
> > BR/pj
> >
> > From: Ranjit Avasarala mailto:ranjitka...@gmail.com>>
> > Sent: den 22 januari 2021 18:02
> > To: Sundbaum Per-Johan (Telenor Sverige AB)
> > mailto:per-johan.sundb...@telenor.se>>
> > Subject: Re: [Sip-implementors] reuse of payload type
> >
> > Hi Sundhaum
> >
> > either A or B should change in order to make a successful call or make
> use of codec conversion.  inst

Re: [Sip-implementors] reuse of payload type

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi !
I believe that that is what the Ue do already, but without taking into account 
previous offers/answers in the dialog.
BR/pj

From: Arun Tagare 
Sent: den 5 februari 2021 06:12
To: Sundbaum Per-Johan (Telenor Sverige AB) 
Cc: Paul Kyzivat ; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] reuse of payload type

Hi All,

Will it solve if you send FULL offer when UE receive re-Invite w/o SDP

pCSCF - VoLTE-phone

INVITE ->

With SDP offer

 <- 180 Ringing

 <- 200OK with SDP answer

ACK ->

re-INVITE ->

without SDP

 <- 200OK with SDP Offer  <<<<<< Here instead of sending negotiated 
offer try sending full offer

ACK ->

With SDP answer





On Mon, Jan 25, 2021 at 7:12 PM Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>> wrote:
Hi again !

I just realized that I didn't answer your question

"It looks like there is an attempt to match on PT 108 with AMR/8000. But the 
codec parameters don't match. Is the expectation that they will be matched by 
PT and then will attempt to interwork the differing codec parameters?"

I'm not sure, but I will  dig some more on the issue !

BR/pj


Sensitivity: Internal

-Original Message-
From: Paul Kyzivat mailto:pkyzi...@alum.mit.edu>>
Sent: den 22 januari 2021 23:44
To: Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>>; Ranjit 
Avasarala mailto:ranjitka...@gmail.com>>; 
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 12:34 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
> Hi !
> My tool is exporting the trace as requested, but it seems the resulting .pcap 
> is not decoded so that one is not to any use.
> I have attached a HTML-version that I hope is at least a little better than 
> my text.

That was fine.

Now to analyze this trace...

Note that IIUC the matching between offer and answer is done by codec name 
(from rtpmap) and codec parameters (from fmtp. IIUC the individual parameters 
in the fmtp need to be matched. The order that they are written is irrelevant.)

(Not by payload type, which can differ on the two ends, though people like it 
better when it doesn't. But in this case it turns out that the PTs do all match 
between a given offer and answer.)

In the first O/A, there is a match between PT 108 on both ends (AMR/8000, 
max-red=0;mode-change-capability=2;mode-change-neighbor=1;mode-change-period=2;mode-set=7).

I imagine PT 116 in the answer is intended to match 116 in the offer.
But it technically doesn't because they don't have matching fmpt values.
I'm guessing it was treated as a match.

In the 2nd O/A, treating it independently of the first one, there are matches 
on 100, 102, 104, 105, 109.

Then question you are asking is about the compatibility of Answer#2 and 
Offer#1. The only match I find is for telephone-event between PT 116 in the 
first answer and PT 100 in the second offer. I think that is what you were 
concerned about. IMO *that* is conforming, since the phone uses
116 in both its first answer and its subsequent offer.

It looks like there is an attempt to match on PT 108 with AMR/8000. But the 
codec parameters don't match. Is the expectation that they will be matched by 
PT and then will attempt to interwork the differing codec parameters? I don't 
think that is how it is supposed to work. But this isn't really my area - I 
know the signaling but not the codec manipulation.

I find the following violations where a UA uses a PT for different 
codec/parameters between the first and 2nd Invites:

pCSCF: 100, 102, 108
phone: 108

Thanks,
Paul



> [cid:image001.png@01D6F0ED.27F177E0]
>
> BR/pj
>
> From: Ranjit Avasarala mailto:ranjitka...@gmail.com>>
> Sent: den 22 januari 2021 18:02
> To: Sundbaum Per-Johan (Telenor Sverige AB)
> mailto:per-johan.sundb...@telenor.se>>
> Subject: Re: [Sip-implementors] reuse of payload type
>
> Hi Sundhaum
>
> either A or B should change in order to make a successful call or make use of 
> codec conversion.  instead of pasting the call flows, it will be better if u 
> could attach the pcap file.
>
> On Fri, Jan 22, 2021 at 10:02 AM Sundbaum Per-Johan (Telenor Sverige AB) 
> mailto:per-johan.sundb...@telenor.se><mailto:per-johan.sundb...@telenor.se<mailto:per-johan.sundb...@telenor.se>>>
>  wrote:
> Much appreciated, thanks !
>
> I have added some more info.
>
>
>
> pCSCF - VoLTE-phone
>
> INVITE ->
>
> With SDP offer
>
>   <- 180 Ringing
>
>   <- 200OK with SDP answer
>
> ACK ->
>
> re-INVITE ->
>
> without SDP
>
>   <- 200OK with SDP Offer
>

Re: [Sip-implementors] reuse of payload type

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi again !

I just realized that I didn't answer your question 

"It looks like there is an attempt to match on PT 108 with AMR/8000. But the 
codec parameters don't match. Is the expectation that they will be matched by 
PT and then will attempt to interwork the differing codec parameters?"

I'm not sure, but I will  dig some more on the issue !
 
BR/pj


Sensitivity: Internal

-Original Message-
From: Paul Kyzivat  
Sent: den 22 januari 2021 23:44
To: Sundbaum Per-Johan (Telenor Sverige AB) ; 
Ranjit Avasarala ; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] reuse of payload type

On 1/22/21 12:34 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
> Hi !
> My tool is exporting the trace as requested, but it seems the resulting .pcap 
> is not decoded so that one is not to any use.
> I have attached a HTML-version that I hope is at least a little better than 
> my text.

That was fine.

Now to analyze this trace...

Note that IIUC the matching between offer and answer is done by codec name 
(from rtpmap) and codec parameters (from fmtp. IIUC the individual parameters 
in the fmtp need to be matched. The order that they are written is irrelevant.)

(Not by payload type, which can differ on the two ends, though people like it 
better when it doesn't. But in this case it turns out that the PTs do all match 
between a given offer and answer.)

In the first O/A, there is a match between PT 108 on both ends (AMR/8000, 
max-red=0;mode-change-capability=2;mode-change-neighbor=1;mode-change-period=2;mode-set=7).

I imagine PT 116 in the answer is intended to match 116 in the offer. 
But it technically doesn't because they don't have matching fmpt values. 
I'm guessing it was treated as a match.

In the 2nd O/A, treating it independently of the first one, there are matches 
on 100, 102, 104, 105, 109.

Then question you are asking is about the compatibility of Answer#2 and 
Offer#1. The only match I find is for telephone-event between PT 116 in the 
first answer and PT 100 in the second offer. I think that is what you were 
concerned about. IMO *that* is conforming, since the phone uses
116 in both its first answer and its subsequent offer.

It looks like there is an attempt to match on PT 108 with AMR/8000. But the 
codec parameters don't match. Is the expectation that they will be matched by 
PT and then will attempt to interwork the differing codec parameters? I don't 
think that is how it is supposed to work. But this isn't really my area - I 
know the signaling but not the codec manipulation.

I find the following violations where a UA uses a PT for different 
codec/parameters between the first and 2nd Invites:

pCSCF: 100, 102, 108
phone: 108

Thanks,
Paul



> [cid:image001.png@01D6F0ED.27F177E0]
> 
> BR/pj
> 
> From: Ranjit Avasarala 
> Sent: den 22 januari 2021 18:02
> To: Sundbaum Per-Johan (Telenor Sverige AB) 
> 
> Subject: Re: [Sip-implementors] reuse of payload type
> 
> Hi Sundhaum
> 
> either A or B should change in order to make a successful call or make use of 
> codec conversion.  instead of pasting the call flows, it will be better if u 
> could attach the pcap file.
> 
> On Fri, Jan 22, 2021 at 10:02 AM Sundbaum Per-Johan (Telenor Sverige AB) 
> mailto:per-johan.sundb...@telenor.se>> wrote:
> Much appreciated, thanks !
> 
> I have added some more info.
> 
> 
> 
> pCSCF - VoLTE-phone
> 
> INVITE ->
> 
> With SDP offer
> 
>   <- 180 Ringing
> 
>   <- 200OK with SDP answer
> 
> ACK ->
> 
> re-INVITE ->
> 
> without SDP
> 
>   <- 200OK with SDP Offer
> 
> ACK ->
> 
> With SDP answer
> 
> 
> 
> 
> 
> SDP in initial INVITE
> SDP PDU
>   v=0
>   o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
>   s=-
>   c=IN IP6 2a02:1400:10:1::4
>   t=0 0
>   m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
>   b=AS:141
>   a=rtpmap:108 AMR/8000
>   a=fmtp:108 mode-set=7; mode-change-period=2; 
> mode-change-capability=2; mode-change-neighbor=1; max-red=0
>   a=rtpmap:102 AMR/8000
>   a=fmtp:102 mode-set=7; max-red=0
>   a=rtpmap:8 PCMA/8000
>   a=rtpmap:100 AMR/8000
>   a=fmtp:100 mode-change-period=2; mode-change-capability=2; 
> mode-change-neighbor=1; max-red=0
>   a=rtpmap:96 AMR/8000
>   a=fmtp:96 max-red=0
>   a=rtpmap:0 PCMU/8000
>   a=rtpmap:116 telephone-event/8000
>   a=ptime:20
>   a=maxptime:20
>   a=rtpmap:111 telephone-event/16000
> 
> SDP in 200OK from VoLTE-phone with SDP as answer on initial INVITE
>   
> o=sip:+46708xxx...@ims.mnc008.mcc240.3

Re: [Sip-implementors] reuse of payload type

[Sundbaum Per-Johan (Telenor Sverige AB)]

Great, thank you !
BR/pj


Sensitivity: Internal

-Original Message-
From: Paul Kyzivat  
Sent: den 22 januari 2021 23:44
To: Sundbaum Per-Johan (Telenor Sverige AB) ; 
Ranjit Avasarala ; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] reuse of payload type

On 1/22/21 12:34 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
> Hi !
> My tool is exporting the trace as requested, but it seems the resulting .pcap 
> is not decoded so that one is not to any use.
> I have attached a HTML-version that I hope is at least a little better than 
> my text.

That was fine.

Now to analyze this trace...

Note that IIUC the matching between offer and answer is done by codec name 
(from rtpmap) and codec parameters (from fmtp. IIUC the individual parameters 
in the fmtp need to be matched. The order that they are written is irrelevant.)

(Not by payload type, which can differ on the two ends, though people like it 
better when it doesn't. But in this case it turns out that the PTs do all match 
between a given offer and answer.)

In the first O/A, there is a match between PT 108 on both ends (AMR/8000, 
max-red=0;mode-change-capability=2;mode-change-neighbor=1;mode-change-period=2;mode-set=7).

I imagine PT 116 in the answer is intended to match 116 in the offer. 
But it technically doesn't because they don't have matching fmpt values. 
I'm guessing it was treated as a match.

In the 2nd O/A, treating it independently of the first one, there are matches 
on 100, 102, 104, 105, 109.

Then question you are asking is about the compatibility of Answer#2 and 
Offer#1. The only match I find is for telephone-event between PT 116 in the 
first answer and PT 100 in the second offer. I think that is what you were 
concerned about. IMO *that* is conforming, since the phone uses
116 in both its first answer and its subsequent offer.

It looks like there is an attempt to match on PT 108 with AMR/8000. But the 
codec parameters don't match. Is the expectation that they will be matched by 
PT and then will attempt to interwork the differing codec parameters? I don't 
think that is how it is supposed to work. But this isn't really my area - I 
know the signaling but not the codec manipulation.

I find the following violations where a UA uses a PT for different 
codec/parameters between the first and 2nd Invites:

pCSCF: 100, 102, 108
phone: 108

Thanks,
Paul



> [cid:image001.png@01D6F0ED.27F177E0]
> 
> BR/pj
> 
> From: Ranjit Avasarala 
> Sent: den 22 januari 2021 18:02
> To: Sundbaum Per-Johan (Telenor Sverige AB) 
> 
> Subject: Re: [Sip-implementors] reuse of payload type
> 
> Hi Sundhaum
> 
> either A or B should change in order to make a successful call or make use of 
> codec conversion.  instead of pasting the call flows, it will be better if u 
> could attach the pcap file.
> 
> On Fri, Jan 22, 2021 at 10:02 AM Sundbaum Per-Johan (Telenor Sverige AB) 
> mailto:per-johan.sundb...@telenor.se>> wrote:
> Much appreciated, thanks !
> 
> I have added some more info.
> 
> 
> 
> pCSCF - VoLTE-phone
> 
> INVITE ->
> 
> With SDP offer
> 
>   <- 180 Ringing
> 
>   <- 200OK with SDP answer
> 
> ACK ->
> 
> re-INVITE ->
> 
> without SDP
> 
>   <- 200OK with SDP Offer
> 
> ACK ->
> 
> With SDP answer
> 
> 
> 
> 
> 
> SDP in initial INVITE
> SDP PDU
>   v=0
>   o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
>   s=-
>   c=IN IP6 2a02:1400:10:1::4
>   t=0 0
>   m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
>   b=AS:141
>   a=rtpmap:108 AMR/8000
>   a=fmtp:108 mode-set=7; mode-change-period=2; 
> mode-change-capability=2; mode-change-neighbor=1; max-red=0
>   a=rtpmap:102 AMR/8000
>   a=fmtp:102 mode-set=7; max-red=0
>   a=rtpmap:8 PCMA/8000
>   a=rtpmap:100 AMR/8000
>   a=fmtp:100 mode-change-period=2; mode-change-capability=2; 
> mode-change-neighbor=1; max-red=0
>   a=rtpmap:96 AMR/8000
>   a=fmtp:96 max-red=0
>   a=rtpmap:0 PCMU/8000
>   a=rtpmap:116 telephone-event/8000
>   a=ptime:20
>   a=maxptime:20
>   a=rtpmap:111 telephone-event/16000
> 
> SDP in 200OK from VoLTE-phone with SDP as answer on initial INVITE
>   
> o=sip:+46708xxx...@ims.mnc008.mcc240.3gppnetwork.org<mailto:sip%3a%2b46708xxx...@ims.mnc008.mcc240.3gppnetwork.org>
>  1611316978 0 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
>  s=-
>  c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
>  t=0 0
>  a=sendrecv
>  m=audio 49120 RTP/AVP 108 116
>  b=AS:37
> 

Re: [Sip-implementors] reuse of payload type

[Sundbaum Per-Johan (Telenor Sverige AB)]

Thank you very much !


From: Ranjit Avasarala 
Sent: den 22 januari 2021 18:39
To: Sundbaum Per-Johan (Telenor Sverige AB) 
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] reuse of payload type

Hi Sundbaum
There is a codec mismatch between A and B - either of them have to change or a 
transcoder needs to be used

Regards
Ranjit

On Fri, Jan 22, 2021 at 11:34 AM Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>> wrote:
Hi !
My tool is exporting the trace as requested, but it seems the resulting .pcap 
is not decoded so that one is not to any use.
I have attached a HTML-version that I hope is at least a little better than my 
text.

[cid:image001.png@01D6F0EE.1F78A010]

BR/pj

From: Ranjit Avasarala mailto:ranjitka...@gmail.com>>
Sent: den 22 januari 2021 18:02
To: Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>>
Subject: Re: [Sip-implementors] reuse of payload type

Hi Sundhaum

either A or B should change in order to make a successful call or make use of 
codec conversion.  instead of pasting the call flows, it will be better if u 
could attach the pcap file.

On Fri, Jan 22, 2021 at 10:02 AM Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>> wrote:
Much appreciated, thanks !

I have added some more info.



pCSCF - VoLTE-phone

INVITE ->

With SDP offer

 <- 180 Ringing

 <- 200OK with SDP answer

ACK ->

re-INVITE ->

without SDP

 <- 200OK with SDP Offer

ACK ->

With SDP answer





SDP in initial INVITE
SDP PDU
 v=0
 o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
 s=-
 c=IN IP6 2a02:1400:10:1::4
 t=0 0
 m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
 b=AS:141
 a=rtpmap:108 AMR/8000
 a=fmtp:108 mode-set=7; mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
 a=rtpmap:102 AMR/8000
 a=fmtp:102 mode-set=7; max-red=0
 a=rtpmap:8 PCMA/8000
 a=rtpmap:100 AMR/8000
 a=fmtp:100 mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
 a=rtpmap:96 AMR/8000
 a=fmtp:96 max-red=0
 a=rtpmap:0 PCMU/8000
 a=rtpmap:116 telephone-event/8000
 a=ptime:20
 a=maxptime:20
 a=rtpmap:111 telephone-event/16000

SDP in 200OK from VoLTE-phone with SDP as answer on initial INVITE
 
o=sip:+46708xxx...@ims.mnc008.mcc240.3gppnetwork.org<mailto:sip%3a%2b46708xxx...@ims.mnc008.mcc240.3gppnetwork.org>
 1611316978 0 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
s=-
c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
t=0 0
a=sendrecv
m=audio 49120 RTP/AVP 108 116
b=AS:37
b=RS:462
b=RR:1387
a=rtpmap:108 AMR/8000
a=fmtp:108 mode-set=7; max-red=0; mode-change-capability=2; 
mode-change-period=2; mode-change-neighbor=1
a=rtpmap:116 telephone-event/8000
a=fmtp:116 0-15
a=ptime:20
a=maxptime:20
a=sendrecv


SDP in 200OK from VoLTE-phone with SDP offer as answer on INVITE without SDP
  SDP PDU
 v=0
 
o=sip:+46708...@ims.mnc008.mcc240.3gppnetwork.org<mailto:sip%3a%2b46708...@ims.mnc008.mcc240.3gppnetwork.org>
 1611316978 1 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
 s=-
 c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
 t=0 0
 a=sendrecv
 m=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...@al

Re: [Sip-implementors] reuse of payload type

[Sundbaum Per-Johan (Telenor Sverige AB)]

Much appreciated, thanks !

I have added some more info.



pCSCF - VoLTE-phone

INVITE ->

With SDP offer

 <- 180 Ringing

 <- 200OK with SDP answer

ACK ->

re-INVITE ->

without SDP

 <- 200OK with SDP Offer

ACK ->

With SDP answer





SDP in initial INVITE
SDP PDU
 v=0
 o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
 s=-
 c=IN IP6 2a02:1400:10:1::4
 t=0 0
 m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
 b=AS:141
 a=rtpmap:108 AMR/8000
 a=fmtp:108 mode-set=7; mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
 a=rtpmap:102 AMR/8000
 a=fmtp:102 mode-set=7; max-red=0
 a=rtpmap:8 PCMA/8000
 a=rtpmap:100 AMR/8000
 a=fmtp:100 mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
 a=rtpmap:96 AMR/8000
 a=fmtp:96 max-red=0
 a=rtpmap:0 PCMU/8000
 a=rtpmap:116 telephone-event/8000
 a=ptime:20
 a=maxptime:20
 a=rtpmap:111 telephone-event/16000

SDP in 200OK from VoLTE-phone with SDP as answer on initial INVITE
 o=sip:+46708xxx...@ims.mnc008.mcc240.3gppnetwork.org 1611316978 0 IN 
IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
s=-
c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
t=0 0
a=sendrecv
m=audio 49120 RTP/AVP 108 116
b=AS:37
b=RS:462
b=RR:1387
a=rtpmap:108 AMR/8000
a=fmtp:108 mode-set=7; max-red=0; mode-change-capability=2; 
mode-change-period=2; mode-change-neighbor=1
a=rtpmap:116 telephone-event/8000
a=fmtp:116 0-15
a=ptime:20
a=maxptime:20
a=sendrecv


SDP in 200OK from VoLTE-phone with SDP offer as answer on INVITE without SDP
  SDP PDU
 v=0
 o=sip:+46708...@ims.mnc008.mcc240.3gppnetwork.org 1611316978 1 IN 
IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
 s=-
 c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
 t=0 0
 a=sendrecv
 m=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 
Sent: den 22 januari 2021 16:31
To: Sundbaum Per-Johan (Telenor Sverige AB) ; 
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 restr

Re: [Sip-implementors] reuse of payload type

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi !
Just to be sure, with B-side you mean the VoLTE-phone ?
BR/pj

From: Ranjit Avasarala 
Sent: den 22 januari 2021 15:25
To: Sundbaum Per-Johan (Telenor Sverige AB) 
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] reuse of payload type

Hi Sundbaum

Here the B side should adapt and change the common codec list to suit the one 
received.  so change 100 to AMR/8000. Then the call will be successful.

Regards
Ranjit


On Fri, Jan 22, 2021 at 6:56 AM Sundbaum Per-Johan (Telenor Sverige AB) 
mailto:per-johan.sundb...@telenor.se>> wrote:
Hi !

I have a call scenario where I would appreciate opinions on which side is most 
correct or perhaps least incorrect !

Call is from external operator, but the interesting part is between pCSCF and a 
VoLTE-phone.
(the logs is from between pCSCF and the VoLTE-phone)

pCSCF sends initial INVITE with sdp to UAS(VoLTE-phone)
  SDP PDU
 v=0
 o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
 s=-
 c=IN IP6 2a02:1400:10:1::4
 t=0 0
 m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
 b=AS:141
 a=rtpmap:108 AMR/8000
 a=fmtp:108 mode-set=7; mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
 a=rtpmap:102 AMR/8000
 a=fmtp:102 mode-set=7; max-red=0
 a=rtpmap:8 PCMA/8000
 a=rtpmap:100 AMR/8000
 a=fmtp:100 mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
 a=rtpmap:96 AMR/8000
 a=fmtp:96 max-red=0
 a=rtpmap:0 PCMU/8000
 a=rtpmap:116 telephone-event/8000
 a=ptime:20
 a=maxptime:20
 a=rtpmap:111 telephone-event/16000
later in same dialog an AS sends re-INVITE without SDP which results in 200OK 
answer from UAS(VoLTE-phone) with SDP

  SDP PDU
 v=0
 
o=sip:+46708...@ims.mnc008.mcc240.3gppnetwork.org<mailto:sip%3a%2b46708...@ims.mnc008.mcc240.3gppnetwork.org>
 1611316978 1 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
 s=-
 c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
 t=0 0
 a=sendrecv
 m=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


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. "


BR/pj


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%7Cc29987664daa494844fe08d8bee18faa%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637469223282439333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=TokAARSCmKKLtcL3uOTVJ0sz2bGWI83h6%2BDwQmZzwK8%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] reuse of payload type

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi !

I have a call scenario where I would appreciate opinions on which side is most 
correct or perhaps least incorrect !

Call is from external operator, but the interesting part is between pCSCF and a 
VoLTE-phone.
(the logs is from between pCSCF and the VoLTE-phone)

pCSCF sends initial INVITE with sdp to UAS(VoLTE-phone)
  SDP PDU
 v=0
 o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
 s=-
 c=IN IP6 2a02:1400:10:1::4
 t=0 0
 m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
 b=AS:141
 a=rtpmap:108 AMR/8000
 a=fmtp:108 mode-set=7; mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
 a=rtpmap:102 AMR/8000
 a=fmtp:102 mode-set=7; max-red=0
 a=rtpmap:8 PCMA/8000
 a=rtpmap:100 AMR/8000
 a=fmtp:100 mode-change-period=2; mode-change-capability=2; 
mode-change-neighbor=1; max-red=0
 a=rtpmap:96 AMR/8000
 a=fmtp:96 max-red=0
 a=rtpmap:0 PCMU/8000
 a=rtpmap:116 telephone-event/8000
 a=ptime:20
 a=maxptime:20
 a=rtpmap:111 telephone-event/16000
later in same dialog an AS sends re-INVITE without SDP which results in 200OK 
answer from UAS(VoLTE-phone) with SDP

  SDP PDU
 v=0
 o=sip:+46708...@ims.mnc008.mcc240.3gppnetwork.org 1611316978 1 IN 
IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
 s=-
 c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
 t=0 0
 a=sendrecv
 m=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


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. "


BR/pj


Sensitivity: Internal
___
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

[Sundbaum Per-Johan (Telenor Sverige AB)]

Yes, my bad, you are correct !
BR/pj


Sensitivity: Internal

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
 On Behalf Of Paul Kyzivat
Sent: den 6 augusti 2020 18:05
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SIP Session Refresh RFC 4028

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%2Flist
> s.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementorsdata=02%
> 7C01%7Cper-johan.sundbaum%40telenor.se%7Cb0e9290a7df14515616e08d83a229
> 41d%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637323267478462483
> p;sdata=MEqUSmLNe%2FqAtEjg5Cma9pXD1PJANmtytJUCnWo9i6s%3Dreserved=
> 0 ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementorsdata=02%
> 7C01%7Cper-johan.sundbaum%40telenor.se%7Cb0e9290a7df14515616e08d83a229
> 41d%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637323267478462483
> p;sdata=MEqUSmLNe%2FqAtEjg5Cma9pXD1PJANmtytJUCnWo9i6s%3Dreserved=
> 0
> 

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://eur02.safelinks.protection.outlook.com/?url=https%3

Re: [Sip-implementors] SIP Session Refresh RFC 4028

[Sundbaum Per-Johan (Telenor Sverige AB)]

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

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

Re: [Sip-implementors] SDP version

[Sundbaum Per-Johan (Telenor Sverige AB)]

That seems also like very good sense, Thanks !
BR/pj


Sensitivity: Internal

-Original Message-
From: Dale R. Worley  
Sent: den 23 januari 2020 04:21
To: Sundbaum Per-Johan (Telenor Sverige AB) 
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP version

"Sundbaum Per-Johan (Telenor Sverige AB)"
 writes:
> 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 ?

There are two similar but distinctly different questions that you might be 
asking.

The general principle is "Be conservative in what you produce and liberal in 
what you accept."

If the question is, "Should a device increment the version in an SDP o-line but 
not change anything else?", as you note RFC 4028 says that a device should not 
do that.

If the question is, "If a device receives SDP with an incremented version in 
the o-line that is otherwise identical to the preceding SDP, should it reject 
it?", the device should not reject it.

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

Re: [Sip-implementors] SDP version

[Sundbaum Per-Johan (Telenor Sverige AB)]

And may I add that I agree on your "never trust" point of view !

Great, Thanks !
:-)

Den 22 jan. 2020 18:59 skrev 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
>

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 (Te

Re: [Sip-implementors] SDP version

[Sundbaum Per-Johan (Telenor Sverige AB)]

Great, Thanks !
:-)

Den 22 jan. 2020 18:59 skrev 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: [Si

Re: [Sip-implementors] SDP version

[Sundbaum Per-Johan (Telenor Sverige AB)]

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 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 SD

Re: [Sip-implementors] SDP version

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi !
I don't think that there are any requirements to do that, but never the less 
there are implementations that are doing it, accidentally I guess.
Thanks !
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<mailto: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

Re: [Sip-implementors] SDP version

[Sundbaum Per-Johan (Telenor Sverige AB)]

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<mailto: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] SDP version

[Sundbaum Per-Johan (Telenor Sverige AB)]

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

Re: [Sip-implementors] session refresh

[Sundbaum Per-Johan (Telenor Sverige AB)]

No problem, thank you !
BR/pj


Sensitivity: Internal

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
 On Behalf Of Paul Kyzivat
Sent: den 24 september 2019 16:24
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] session refresh

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

Re: [Sip-implementors] session refresh

[Sundbaum Per-Johan (Telenor Sverige AB)]

Thanks !





-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
 On Behalf Of Philipp Schöning
Sent: den 24 september 2019 12:03
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] session refresh



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



Am Di., 24. Sept. 2019 um 07:40 Uhr schrieb Sundbaum Per-Johan (Telenor Sverige 
AB) mailto:per-johan.sundb...@telenor.se>>:



> 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<mailto:Sip-implementors@lists.cs.columbia.edu>

https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


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

Re: [Sip-implementors] session refresh

[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


Sensitivity: Internal

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu 
 On Behalf Of Paul Kyzivat
Sent: den 24 september 2019 00:27
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] session refresh

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

Re: [Sip-implementors] session refresh

[Sundbaum Per-Johan (Telenor Sverige AB)]

Thank you !

From: Kashif Husain 
Sent: den 24 september 2019 00:04
To: Sundbaum Per-Johan (Telenor Sverige AB) 
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] session refresh

And we can also respond with 200OK as mentioned in rfc3261 with no change in 
our sdp.

"If the user is already a member of the session, and the session

   parameters contained in the session description have not changed, the

   UAS MAY silently accept the INVITE (that is, send a 2xx response

   without prompting the user)."



On Tue, 24 Sep 2019, 03:17 Kashif Husain, 
mailto:kashifhusai...@gmail.com>> wrote:
You can check for SDP version of re-Invite, if its same as previous one then 
its usually intended for session refresh.

Thanks,
-kashif
On Tue, 24 Sep 2019, 02:30 Sundbaum Per-Johan (Telenor Sverige AB), 
mailto:per-johan.sundb...@telenor.se>> 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 ?

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


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

[Sip-implementors] session refresh

[Sundbaum Per-Johan (Telenor Sverige AB)]

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 ?

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

Re: [Sip-implementors] RTP with wrong payload

[Sundbaum Per-Johan (Telenor Sverige AB)]

I couldn't find all the details for my previous example, but I did find a 
similar case where there are a couple of AMR packets sent to PBX that makes the 
PBX decline the call.

I have attached the signaling somewhat anonymized.



Call flow

[cid:image001.png@01D47D1D.5DBD2EF0]

BR/pj



-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: den 15 november 2018 19:27
To: Sundbaum Per-Johan (Telenor Sverige AB); 
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RTP with wrong payload



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>

> [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<mailto: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>

>> [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<mailto:sip-implementors@lists.cs.columbia.edu>

>> Subject: Re: [Sip-implementors] RTP with wrong payload

>>

>> Paul Heitkemper mailto:pheitkem...@iedaudio.com>> 
>> 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 

Re: [Sip-implementors] RTP with wrong payload

[Sundbaum Per-Johan (Telenor Sverige AB)]

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


 
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

[Sundbaum Per-Johan (Telenor Sverige AB)]

Thank you very much Alex, Dale and Paul !
BR/pj


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

Correct -- if the party receiving the G.722 packets did not advertise support 
for the G.722 payload type in its SDP stanza, it should just ignore them if 
they arrive anyway.

On Thu, Nov 15, 2018 at 06:21:14AM +, 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 ?
> 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

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RTP with wrong payload

[Sundbaum Per-Johan (Telenor Sverige AB)]

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 ?
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

Re: [Sip-implementors] RTP with wrong payload

[Sundbaum Per-Johan (Telenor Sverige AB)]

Thank you very much Paul !
BR/pj

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

 

RFC 3550 Section 5.1 

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

-- 

Paul 

On 2018-11-14 01:30, Sundbaum Per-Johan (Telenor Sverige AB) wrote: 

> Thanks !
> Ok, but to be more specific, are there any general recommendations on 
> question like: Should the PBX drop the packets with wrong payload and let the 
> call/session continue or should the PBX also drop the entire call ?
> BR/pj
> 
> -Original Message-
> From: Dale R. Worley [mailto:wor...@ariadne.com]
> Sent: den 14 november 2018 05:25
> To: Sundbaum Per-Johan (Telenor Sverige AB)
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] RTP with wrong payload
> 
> "Sundbaum Per-Johan (Telenor Sverige AB)"
>  writes:
> 
>> Can someone help me getting a link to information regarding how a PBX should 
>> handle the case when for example the codec G.711A is agreed upon, but 
>> somehow there are a couple of G.722 packets received that have the same 
>> ports on UDP level, but clearly belongs to another RTP stream when you look 
>> at sequence numbers, timestamps and SSRC ?
> 
> There's no real definition of "clearly belongs to". If a packet arrives at a 
> port, it is processed according to the usage that has been negotiated for 
> that port.
> 
> Dale
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors [1]
 

Links:
--
[1] 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

[Sundbaum Per-Johan (Telenor Sverige AB)]

Thanks !
Ok, but to be more specific, are there any general recommendations on question 
like: Should the PBX drop the packets with wrong payload and let the 
call/session continue or should the PBX also drop the entire call ?
BR/pj

-Original Message-
From: Dale R. Worley [mailto:wor...@ariadne.com] 
Sent: den 14 november 2018 05:25
To: Sundbaum Per-Johan (Telenor Sverige AB)
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RTP with wrong payload

"Sundbaum Per-Johan (Telenor Sverige AB)"
 writes:
> Can someone help me getting a link to information regarding how a PBX 
> should handle the case when for example the codec G.711A is agreed 
> upon, but somehow there are a couple of G.722 packets received that 
> have the same ports on UDP level, but clearly belongs to another RTP 
> stream when you look at sequence numbers, timestamps and SSRC ?

There's no real definition of "clearly belongs to".  If a packet arrives at a 
port, it is processed according to the usage that has been negotiated for that 
port.

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

[Sip-implementors] RTP with wrong payload

[Sundbaum Per-Johan (Telenor Sverige AB)]

Hi !
Can someone help me getting a link to information regarding how a PBX should 
handle the case when for example the codec G.711A is agreed upon, but somehow 
there are a couple of G.722 packets received that have the same ports on UDP 
level, but clearly belongs to another RTP stream when you look at sequence 
numbers, timestamps and SSRC ?
Thanks !
BR/pj
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors