Discussion:
[Sip-implementors] Fwd: Multiple 183 w/SDP along with PRACK
NK
2014-07-10 16:22:25 UTC
Permalink
Dear All,

I have call flow like where Vendor sends 183 w/SDP included Rseq and
customer sents the PRACK and 200 OK from vendor.

After that vendor is again sending 1~2 183 w/SDP where it is not changing
anything in SDP but only asking for PRACK by sending RSEQ. I checked the
RFC , but cannot see anything like which says UAS cannot send multiple 183
w/SDP.

Can you please help on this, whether any UAS can send multiple 183 w/SDP
where it is asking for PRACK? Is it valid call flow, because i cannot see
anything RFC.

Regards,
Nitin Kapoor
Brett Tate
2014-07-10 16:50:24 UTC
Permalink
Post by NK
I have call flow like where Vendor sends
183 w/SDP included Rseq and customer sents
the PRACK and 200 OK from vendor.
After that vendor is again sending 1~2
183 w/SDP where it is not changing anything
in SDP but only asking for PRACK by sending RSEQ.
I checked the RFC , but cannot see anything like
which says UAS cannot send multiple 183 w/SDP.
Concerning the additional 18x messages, I assume that To tags did not
change and that the RSeq value was incremented.
Post by NK
Can you please help on this, whether any UAS can
send multiple 183 w/SDP where it is asking for PRACK?
Is it valid call flow, because i cannot see
anything RFC.
RFC 6337 section 3.1.1 indicates the following (F9 is second 18x when
prior 18x contained answer SDP):

"The UAS does not include SDP in responses F9 and F12. However, the
UAC should prepare to receive SDP bodies in F9 and/or F12, and just
ignore them, to handle a peer that does not conform to the
recommended implementation."
NK
2014-07-10 16:58:37 UTC
Permalink
Hi Brett,

Thanks a lot for your reply. Below is my understanding, please advise if it
is correct.
Post by NK
I have call flow like where Vendor sends
183 w/SDP included Rseq and customer sents
the PRACK and 200 OK from vendor.
After that vendor is again sending 1~2
183 w/SDP where it is not changing anything
in SDP but only asking for PRACK by sending RSEQ.
I checked the RFC , but cannot see anything like
which says UAS cannot send multiple 183 w/SDP.
Concerning the additional 18x messages, I assume that To tags did not
change and that the RSeq value was incremented.


*## Yes you are correct. Only Rseq Value is increasing, TO tag is same for
all 183.*
Post by NK
Can you please help on this, whether any UAS can
send multiple 183 w/SDP where it is asking for PRACK?
Is it valid call flow, because i cannot see
anything RFC.
RFC 6337 section 3.1.1 indicates the following (F9 is second 18x when
prior 18x contained answer SDP):

"The UAS does not include SDP in responses F9 and F12. However, the
UAC should prepare to receive SDP bodies in F9 and/or F12, and just
ignore them, to handle a peer that does not conform to the
recommended implementation."

*### As per this paragraph and i checked the RFC..Which means UAS can send
additional 183 w/SDP or RSEQ, and UAC simply can ignore this.*

Please advise if my understanding is correct.

Regards,
Nitin Kapoor
Post by NK
Post by NK
I have call flow like where Vendor sends
183 w/SDP included Rseq and customer sents
the PRACK and 200 OK from vendor.
After that vendor is again sending 1~2
183 w/SDP where it is not changing anything
in SDP but only asking for PRACK by sending RSEQ.
I checked the RFC , but cannot see anything like
which says UAS cannot send multiple 183 w/SDP.
Concerning the additional 18x messages, I assume that To tags did not
change and that the RSeq value was incremented.
Post by NK
Can you please help on this, whether any UAS can
send multiple 183 w/SDP where it is asking for PRACK?
Is it valid call flow, because i cannot see
anything RFC.
RFC 6337 section 3.1.1 indicates the following (F9 is second 18x when
"The UAS does not include SDP in responses F9 and F12. However, the
UAC should prepare to receive SDP bodies in F9 and/or F12, and just
ignore them, to handle a peer that does not conform to the
recommended implementation."
Brett Tate
2014-07-10 17:07:45 UTC
Permalink
Post by NK
As per this paragraph and i checked the RFC..
Which means UAS can send additional 183 w/SDP
or RSEQ, and UAC simply can ignore this.
I'm not sure what you mean by "or RSEQ".

The UAC does not ignore the 18x. The RFC's indicate to ignore the SDP since
it is not officially a new offer or answer.
NK
2014-07-10 17:13:17 UTC
Permalink
Hi Brett,

I mean to say in second or third 183 w/SDP "TO" tag is same but "RSeq:
2779" is incrementing.

I am sorry but i am still not clear on second part, is that 2~3 183 w/sdp
is valid and call can be processed? As you mentioned if UAS sends the 183
w/SDP where it is requesting for PRACK again then UAC can be prepare to
receive SDP. Also it can ignore it.

Regards,
Nitin Kapoor
Post by Brett Tate
Post by NK
As per this paragraph and i checked the RFC..
Which means UAS can send additional 183 w/SDP
or RSEQ, and UAC simply can ignore this.
I'm not sure what you mean by "or RSEQ".
The UAC does not ignore the 18x. The RFC's indicate to ignore the SDP since
it is not officially a new offer or answer.
Brett Tate
2014-07-10 17:27:52 UTC
Permalink
is that 2~3 183 w/sdp is valid and call can be processed?
Yes; it is valid. However, RFC 6337 recommends to not include the SDP.

Maybe you will find the following snippet more clear concerning how the UAC
MUST handle SDP contained within the subsequent 18x/2xx responses.

RFC 3261 section 13.2.1:

"The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE."
NK
2014-07-14 22:04:19 UTC
Permalink
Hi Brett,

Thanks a lot for your help!!

Regards,
Nitin Kapoor
Post by Brett Tate
is that 2~3 183 w/sdp is valid and call can be processed?
Yes; it is valid. However, RFC 6337 recommends to not include the SDP.
Maybe you will find the following snippet more clear concerning how the UAC
MUST handle SDP contained within the subsequent 18x/2xx responses.
"The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE."
Loading...