UE2 is operating in a non-conforming manner.
In this (and most) cases, the behavior when dealing with a
non-conforming message is not defined. Its up to you to decide what you
want to do. You can experiment with what works best for you. There is no
guarantee that anything you do will work *well*, or in a consistent way.
The main thing you should do is contact the vendor of the offending
device, and ask them to fix their device.
Thanks,
Paul
On 1/6/12 3:22 AM, Kumar, Hemanth wrote:
> Hi All,
> This is a B2BUA scenario.
> This issue is as shown below
> UE1 ----- INVITE [no SDP, Require:100 Rel] ------------ > B2BUA -------
> INVITE [no SDP, Require:100 Rel] -----------> UE2
> B2BUA *<------- 183 [no SDP] ------------- UE2 *
> When an INVITE is sent with require 100rel and without an offer,
> misbehaving UE2 sends 18x without SDP.
> RFC 6337 does not define the behavior of UAC in this case.
> There could be 2 possible solutions:
> 1. Tear down the call by sending CANCEL on egress leg and 420 Bad
> extension response on ingress leg as shown below
> UE1 ----- INVITE [no SDP, Require:100 Rel] ------------ > B2BUA-------
> INVITE [no SDP, Require:100 Rel] -----------> UE2
> UE1 <----- 420 Bad extension ------------------------------
> B2BUA<------- 183 [no SDP] ---------------------------------- UE2
> B2BUA ------- CANCEL ------------------------------------------> UE2
> 2. Ignore 18x received and wait for reliable response containing SDP on
> the egress leg. On receiving the response, send 18x reliably with SDP
> followed by 200 OK with the same SDP on the ingress leg. This ensures
> backward compatability.
> UE1 ----- INVITE [no SDP, Require:100 Rel] ------------ > B2BUA -------
> INVITE [no SDP, Require:100 Rel] -----------> UE2
> B2BUA <---------- 183 [no SDP] ---------------------------------- UE2
> UE1 <----- 183 [with SDP] --------------------------------- B2BUA
> <----------- 200 [with SDP] ------------------------------ UE2
> UE1 <----- 200 [with SDP] --------------------------------- B2BUA
> I would appreciate if you could share your comments on both the
> solutions and propose alternate solution if any.
> Regards
> Hemanth
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Kumar, Hemanth
> Sent: Wednesday, January 04, 2012 8:39 PM
> To: [email protected]
> Cc: Paul Kyzivat
> Subject: [Sip-implementors] Expected behavior for an INVITE sent without
> an offer
> Hi,
> What should be the behavior of UAC when an INVITE is sent without offer
> and Require 100rel and it receives non-reliable/reliable 18x response
> without SDP?
> Should the transaction be terminated by sending CANCEL?
> The same scenario was given as comment which has not been addressed in
> offer/answer draft-ietf-sipping-sip-offeranswer-03
> http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-sip-offeranswer-03-seth.txt
> " 3. Section 1.1 :
> Comment :- We should define the behavior for a UAC which sends out an
> INVITE without SDP and receives the first non-failure reliable response
> without an Offer, due to the UAS not conforming to the draft. As this
> being an open point can lead to multiple different implementations. Does
> the UAC clear the call or send a PRACK and wait for the offer in
> subsequent reliable responses."
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
