subject:"Re\: \[Sip\-implementors\] 400 BadRequest"

Re: [Sip-implementors] 400 BadRequest

2021-02-23 Thread 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 n

Re: [Sip-implementors] 400 BadRequest

2021-02-23 Thread Paul Kyzivat


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

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


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


Thanks,
Paul


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

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

BR/pj


Sensitivity: Internal

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

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

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


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

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


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

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

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

Thanks,
Paul


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

This behavior is according to Function Specification Session Initiation 
Protocol, 1/155 17 FAY

Re: [Sip-implementors] 400 BadRequest

2021-02-23 Thread 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%2

Re: [Sip-implementors] 400 BadRequest

2021-02-23 Thread Paul Kyzivat

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

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

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

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

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

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

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

Thanks,
Paul

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

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

BR/pj

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

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

Re: [Sip-implementors] 400 BadRequest

Re: [Sip-implementors] 400 BadRequest

Re: [Sip-implementors] 400 BadRequest

Re: [Sip-implementors] 400 BadRequest

4 matches

Site Navigation

Mail list logo

Footer information