Hi Brett,
Thank You for the analysis.Yes, it is true that even if UAC doesn't support
TIMER but as per RFC it must be ready to accept SESSION EXPIRY from UAS. Also i
would like to bring in your notice that BYE was sent within 4 secs.So i have
done detailed analysis and observed that
SIP
calls are failing due to differing session versions received in the SDP
of the 183 and 200ok messages. The MSC server releases the call
immediately due to unexpected SDP version received in 200 OK.
Source
Destination
-------------INVITE
------------->
<----------100 trying-------------
<-------183 session
progress------ SDP:Session
version 37999005 …. o=HuaweiSoftX3000 37999005 37999005 IN IP4 10.6.197.50
<-------180
Ringing
------
SDP:Session version 37999006….. o=HuaweiSoftX3000
37999005 37999006 IN IP4
10.6.197.50
<-----------200
OK----------------
SDP:Session version 37999007….. o=HuaweiSoftX3000
37999005 37999007 IN IP4
10.6.197.50
---------
ACK message ---->
------- BYE ------------------>
<-----------200
OK----------------
MSC
will release the call .This is normal expected
behavior.
As per RFC4566, the session
version is only increased if a modification is made to the session data. In
this case, the call is only being answered, no new session is being established
neither the SDP being
modified, hence it is expected that the same session number is used for 200 OK.
RFC 4566:
5.2.
Origin ("o=")
o=<username>
<sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
<sess-version> is a version number for this
session description. Its usage is up to the creating tool, so long
as <sess-version> is
increased when a modification is made to the
session data. Again, it is RECOMMENDED that an NTP format timestamp
is used.
According to another spec RFC 3264, this incrementing of version
implies new offer:
RFC 3264:
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.
Please have a look at SDP of all three MESSAGES. Except the
session version , everything else is same which means that there is no new
negotiation and hence session version should also not change.
Status Line
SIP/2.0 183 Session
Progress
Body
SDP
PDU
v=0
o=HuaweiSoftX3000
37999005 37999005 IN IP4
10.6.197.50
s=Sip
Call
c=IN
IP4 10.6.197.50
t=0
0
m=audio
14436 RTP/AVP 18 97
a=rtpmap:18
G729/8000
a=ptime:20
a=fmtp:18
annexb=no
a=sqn:
0
a=cdsc:
1 image udptl t38
a=rtpmap:97
telephone-event/8000
a=fmtp:97
0-15
Status Line
SIP/2.0 180 Ringing
Body
SDP
PDU
v=0
o=HuaweiSoftX3000
37999005 37999006 IN IP4
10.6.197.50
s=Sip
Call
c=IN
IP4 10.6.197.50
t=0
0
m=audio
14436 RTP/AVP 18 97
a=rtpmap:18
G729/8000
a=ptime:20
a=fmtp:18
annexb=no
a=sqn:
0
a=cdsc:
1 image udptl t38
a=rtpmap:97
telephone-event/8000
a=fmtp:97
0-15
Status Line
SIP/2.0 200 Ok
Body
SDP
PDU
v=0
o=HuaweiSoftX3000
37999005 37999007 IN IP4
10.6.197.50
s=Sip
Call
c=IN
IP4 10.6.197.50
t=0
0
m=audio
14436 RTP/AVP 18 97
a=rtpmap:18
G729/8000
a=ptime:20
a=fmtp:18
annexb=no
a=sqn:
0
a=cdsc:
1 image udptl t38
a=rtpmap:97
telephone-event/8000
a=fmtp:97
0-15
Please share your opinion if you have any thing else is responsible for sending
BYE.
Regards
Sampat
On Saturday, 22 February 2014 11:38 PM, Brett Tate <br...@broadsoft.com> wrote:
> Can anyone explain me the reason for sending BYE by UAC.
You didn't provide enough information (such as time interval before BYE
sent). For instance if BYE sent immediately upon receiving 200 response
for INVITE, the SDP might be malformed or there was unexpected
offer/answer behavior. I mention it because there was a 183 (likely with
SDP), 180, and subsequent 2xx with SDP. If the 2xx's SDP is different
(assuming same dialog), there can be interoperability issues since RFC
3261 indicates to ignore the SDP (although some vendors non compliantly
send it as updated answer or new offer per configuration).
Since the BYE can be sent for variety of reasons, you might want to ask
the client vendor (assuming BYE not instigated by user) why they sent BYE.
> I want to know, if UAC does not support "TIMER"
> functionality whether UAS can send this session
> expires with support of "timer" in 200ok.
Yes; see RFC 4028 Table 2.
> is this the reason for sending BYE by UAC.
I doubt it since the UAC didn't indicate timer support. However if UAC is
actually a B2BUA and BYE sent around expiration time, it could be expected
since answering device didn't refresh the session within the 200's
Session-Expires interval.
--
This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
