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:+46xxxxxxxxx SIP/2.0
Headers
To: tel:+46xxxxxxxxx
From: "46xxxxxxxxx"
<sip:+46xxxxxx...@sip.telenor.se;user=phone>;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=z9hG4bK41638c83800fcb7a519a2b35198b6d9dk555555yaaaaacaaaaabaaaaaaa3Zqkv7ad0qlnsabaaiaqaaaaacaaaaaaaaqaaaaaa
Via: SIP/2.0/TCP 10.49.247.89:5160;branch=z9hG4bK1637070684-451807432
Route: <sip:mss1-msrn-mgcf.ims2.se.telenor.net;lr>
Record-Route:
<sip:3zqkv7%20caqmuk1zdgaaaaax6gtsgbabaiaaaaahsip%3a%2b46733903559%40ims.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: <sip:10.49.24.132>;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: "xxxxxxx xxxx" <sip:virtim004xxx...@sip.telenor.se>
P-Asserted-Identity: "46xxxxxxxxx" <tel:+46xxxxxxxxx>
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:
"46xxxxxxxxx"<sip:+46xxxxxx...@sip.telenor.se;user=phone>;reason=unknown;counter=4;answered-count=1;diversion-inhibited
Diversion:
"46xxxxxxxxx"<sip:+46xxxxxx...@sip.telenor.se;user=phone>;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
<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%26FN%3D1_15517-FAY112172_11Uen.B.html%23TOP&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7Cd194ec3aa30c41fbc41f08d8d827b3d6%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637497012324792365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1gLytNI4xAgcQ%2FTRGioNol79y5U5Y96UJxxqSK%2BihIk%3D&reserved=0>
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=04%
> 7C01%7Cper-johan.sundbaum%40telenor.se%7Cd194ec3aa30c41fbc41f08d8d827b
> 3d6%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637497012324802360%7C
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C1000&sdata=3baBoB3NUWrW2JcEdUuNhqVLjQ0LM3ToU2
> nxFnYPAAs%3D&reserved=0
>
_______________________________________________
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-implementors&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7Cd194ec3aa30c41fbc41f08d8d827b3d6%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637497012324802360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3baBoB3NUWrW2JcEdUuNhqVLjQ0LM3ToU2nxFnYPAAs%3D&reserved=0
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
