Subject: [Sipping] Forked unreliable 1xx responses created txns????

From: [email-masked]
Date: Fri, 7 Sep 2007 10:07:33 +0530

Should the transaction layer create multiple transactions for forked 
unreliable 1xx responses?

Thanks and Regards,
 Preethi..
------------------------------------------------------------------------------
Preethi Sadasivan,
Software Engineer,
ARICENT ,
Bangalore.
------------------------------------------------------------------------------

***********************  Aricent-Private   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 07 Sep 2007 07:43:45 +0200

Preethi,

The answer is no, transactions get created when a _request_ is sent 
(client transaction) or received (server transaction)

Regards,
Jeroen

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Fri, 7 Sep 2007 12:56:32 +0530

We have a scenario where the UA  receives the 1xx from one call-leg and 
2xx from different call-leg for an INVITE(intial) sent and we want to 
delete the first call-leg(on which we received the 1xx), then how do we 
handle this 2xx??? Do we need to still use the same transaction or we 
need to create a new transaction??

Thanks and Regards,
 Preethi..

Jeroen van Bemmel <[email-masked]> 
09/07/2007 11:13 AM

To
Preethi Sadasivan/BLR/HSS@HSS
cc
[email-masked]
Subject
Re: [Sipping] Forked unreliable 1xx responses created txns????

Preethi,

Regards,
Jeroen

> the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be 
> circulated or used for any purpose other than for what it is intended. 
If you have received this message in error, 
> please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of 
this message. Aricent accepts no responsibility for

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 7 Sep 2007 09:35:07 -0400

> We have a scenario where the UA  receives the 1xx from 
> one call-leg and 2xx from different call-leg for 
> an INVITE (intial) sent and we want to delete the first 
> call-leg (on which we received the 1xx), then how do 
> we handle this 2xx???

Per rfc3261 section 16.7 step 10: "If the forwarded response was a final
response, the proxy MUST generate a CANCEL request for all pending
client transactions associated with this response context."

You can assume that the proxy canceled the 18x legs if it sent the 2xx
on a different leg.  Thus there is no reason for UA to send a useless
CANCEL since the forking proxy is already required to generate the
CANCEL.

---

From: [email-masked]
Date: Mon, 10 Sep 2007 16:27:09 -0400

From: [email-masked]

   Should the transaction layer create multiple transactions for
   forked unreliable 1xx responses?

If a UAC receives multiple responses with different to-tags, then it
must (in some manner) record early dialogs for all of them.  (The
reason is that it might receive an INVITE-with-Replaces specifying any
of the to-tags, and the UAC would have to accept it, whereas an
INVITE-with-Replaces with a to-tag that had not been seen must
generate a 481 response.)  The usual method is to create a separate
transaction state for each one.

Upon receiving a 2xx response to the request:

If the UAC itself forked the request to multiple destinations (RFC
3261) is is required to send CANCELs to all of the forks except the
fork which returned the 2xx response (which can be determined by its
branch parameter).  Or, (RFC 3841) the UAC may wish to maintain other
established dialogs with other UACs, in which case it doesn't send
CANCELs.

If forking was done by downstream proxies, if a 2xx response is
obtained from one fork, it is required to (RFC 3261) send CANCELs to
all other forks, unless (RFC 3841) the request contains
"Request-Disposition: no-cancel".

Dale