see embedded comments
----- Original Message -----
From: "Harpreet Ahluwalia" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 19, 2001 6:23 PM
Subject: [Sip-implementors] another problem related to multiple call legs at
UAC
> Hi,
>
> Taking up the same scenarios where I the UAC had sent an INVITE to my
> proxy & it forked it further.
> Now, the UAC gets 18Xs from multiple locations, with the only difference
> being the tag in the "To" header.
> Assuming the UAC further gets a 200 & wants to CANCEL the other 18X it
> got, where should it send the CANCEL to? THE UAC is using UDP & there
> was no contact in the 18x received. Is the UAC expected to store the IP
> address from which it got the 18X & reuse the same while sending CANCEL.
> I don't think that is the intent.
The CANCEL must be sent to the same destination as the original request. You
cannot send it to the UAS that generated the 18x even if it included a
Contact header. If you did, all the proxies in the middle would still have
transaction state for the request.
>
> Section 5.2 of bis 03.txt says " ...The Request-URI, topmost Via,
> Call-ID, To, the numeric part of CSeq
> and From header fields in the CANCEL request are identical to those
> in the original request being cancelled, including tags. This allows
> a CANCEL request to be matched with the request it cancels"
>
> If that is the case then how will the CANCEL be related to the 2nd call
> leg, because the CANCEL does not have the to tag of the 18x response but
> instead it has the whole to header from the original request.
>
The CANCEL should not affect the completed call leg (the one that got a
final response) and hopefully it would reach the forking proxy which would
CANCEL all remaining forked INVITEs.
I don't know if bis talks about this, but I imagine that any stateful proxy
between the UAC and the forking proxy should recognize the multiple "early"
call legs and maintain the transaction until it got a final response on all
the legs it knew about or it got a CANCEL from the UAC or previous hop
server.
>
> Another thing Section 5.2 of bis 03.txt also says that
> "A proxy client generates a CANCEL request for branches without
> a final response after it has forked a request and receives a 2xx or
> 6xx response from one of the branches. "
> Whereas section 17.4, pg. 122 says that
> "After receiving a 2xx, the server MAY terminate all other
> pending requests by sending a CANCEL request"
>
> Note that there is no "MAY" in section 5.2.
>
> I have a basic question here. The intent of the UAC by sending the
> INVITE to the proxy was to open just one call leg, but the proxy's
> forking resulted in formation of multiple call legs. Now why isn't it
> made mandatory in SIP for the proxy to handle all these extra multiple
> call legs & present the UAC with just one 2xx for one call leg only. Why
> is it left as a "MAY" for the proxy to CANCEL the multiple pending call
> legs. As I said earlier the intent of the UAC is to get to the UAS at
> just one location, why should the UAC be troubled with the multiple 2XXs
> from multiple locations.
It is a MAY because there may be some UACs that can accept multiple 200-OK'd
call legs. There is all kinds of fancy stuff a UAC could do with multiple
call legs. If the UAC only wants the first 200-OK, it can accept it. If it
sees another 200-OK, it can just ACK it and send a BYE.
> The proxy has the all the information regarding who all it had forked
> the INVITE to, & in my opinion the proxy is the best entity to CANCEL OR
> BYE the extra call legs, then why has it been left to the UAC to handle
> multiple 2XXs by using the word "MAY" above.
>
I believe the caller preferences draft introduces some mechanisms that would
allow the UAC to indicate to the proxies how it wants multiple call legs
handled.
http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-04.txt
> --
> Regards,
>
> Harpreet Ahluwalia
> Lucent Technologies
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
