Hi
According to the scenario and solutions explained I think there solution 1
does not make a nice solution
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
As B2BUa cancelling what can be a possible session is not good
As far as solution 2 is considered
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
Ignosing 183 response without SDP totally makes sense but there are some
considerations to be done
UE1 if on UDP would be expecting 183 with message_timer if it expires same
invite would be retransmitted, to avoid that 180 response can be sent
without sdp.
The momment 200 OK arrives 200OK can be issued without 183 with SDP and
sending the same in 200 that does not make sense
Reg
Sai
On Fri, Jan 20, 2012 at 4:37 PM, Sreenath Kulkarni <
sreenathkulka...@yahoo.co.in> wrote:
> Hello Hemanth,
>
> According to RFC3262 section 5 the below statement
>
> "If a reliable provisional response is the first reliable message sent
> back to the UAC, and the INVITE did not contain an offer, one MUST appear
> in that reliableprovisional response."
>
> UAS MUST send Offer in 183 response
>
> In your scenario I suggest the B2BUA to terminate the call by sending
> CANCEL to UE2 and 487 response to UE1.
>
> Thanks & Regards,
> Sreenath
>
>
>
> ________________________________
> From: "Kumar, Hemanth" <hku...@sonusnet.com>
> To: "sip-implementors@lists.cs.columbia.edu" <
> sip-implementors@lists.cs.columbia.edu>
> Cc: Paul Kyzivat <pkyzi...@alum.mit.edu>
> Sent: Friday, 6 January 2012 1:52 PM
> Subject: Re: [Sip-implementors] Expected UAC behavior when a
> reliable/non-reliable 18x without SDP is recieved for an INVITE sent
> without an offer and require 100 rel
>
> 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: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Kumar,
> Hemanth
> Sent: Wednesday, January 04, 2012 8:39 PM
> To: sip-implementors@lists.cs.columbia.edu
> 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
> Sip-implementors@lists.cs.columbia.edu<mailto:
> Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
--
With Regards
Sairam
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
