RFC 3261 Section 17.1.3
17.1.3 Matching Responses to Client Transactions
When the transport layer in the client receives a response, it has to
determine which client transaction will handle the response, so that
the processing of Sections 17.1.1 and 17.1.2 can take place. The
branch parameter in the top Via header field is used for this
purpose. A response matches a client transaction under two
conditions:
1. If the response has the same value of the branch parameter in
the top Via header field as the branch parameter in the top
Via header field of the request that created the transaction.
2. If the method parameter in the CSeq header field matches the
method of the request that created the transaction. The
method is needed since a CANCEL request constitutes a
different transaction, but shares the same value of the branch
parameter.
Somesh
* Please do not take print out of this e-mail unless its absolutely necessary *
-----Original Message-----
From: Attila Sipos [mailto:[email protected]]
Sent: Mon 3/2/2009 2:15 PM
To: Somesh S. Shanbhag; priyank luthra; [email protected]
Subject: RE: [Sip-implementors] Branch parameter as transaction
identifierv/sCseq
When you send the CANCEL, won't the branch be the same as in the INVITE?
So I can't see what extra advantage is offered by the CSeq.
Can you explain.
________________________________
From: Somesh S. Shanbhag [mailto:[email protected]]
Sent: 02 March 2009 08:25
To: Attila Sipos; priyank luthra; [email protected]
Subject: RE: [Sip-implementors] Branch parameter as transaction
identifierv/sCseq
CSeq method is used to identify the transaction along with branch, when
a CANCEL
request is processed.
Somesh
* Please do not take print out of this e-mail unless its absolutely
necessary *
-----Original Message-----
From: [email protected] on behalf of Attila
Sipos
Sent: Mon 3/2/2009 1:53 PM
To: priyank luthra; [email protected]
Subject: Re: [Sip-implementors] Branch parameter as transaction
identifierv/sCseq
Simply:
1. transaction instance is created and a branch parameter is associated
with it
2. the branch parameter is placed into a request
3. response is received with the same branch parameter
4. transaction instance can be destroyed
As far as I can tell, you don't need to use CSeq to identify a
transaction.
I believe branch was not used by UA's in the orignal SIP RFC (RFC2543)
so CSeq and Method was originally used to match transactions. However
in RFC3261, branch is used by UA's so CSeq is not now needed for
transaction matching.
Regards,
Attila
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
priyank luthra
Sent: 02 March 2009 06:50
To: [email protected]
Subject: [Sip-implementors] Branch parameter as transaction identifier
v/sCseq
Hi all,
I would like to know why and how is a branch parameter in Via header
able to identify a transaction, and if so, why do we need CSeq header to
identify a transaction?
--
Regards,
Priyank
_______________________________________________
Sip-implementors mailing list
[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
________________________________
EMAIL DISCLAIMER : This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity
to whom they are addressed. Any unauthorised distribution or copying is
strictly prohibited. If you receive this transmission in error, please
notify the sender by reply email and then destroy the message. Opinions,
conclusions and other information in this message that do not relate to
official business of Mascon shall be understood to be neither given nor
endorsed by Mascon. Any information contained in this email, when
addressed to Mascon clients is subject to the terms and conditions in
governing client contract.
Whilst Mascon takes steps to prevent the transmission of viruses via
e-mail, we can not guarantee that any email or attachment is free from
computer viruses and you are strongly advised to undertake your own
anti-virus precautions. Mascon grants no warranties regarding
performance, use or quality of any e-mail or attachment and undertakes
no liability for loss or damage, howsoever caused.
EMAIL DISCLAIMER : This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. Any unauthorised distribution or copying is strictly
prohibited. If you receive this transmission in error, please notify the sender
by reply email and then destroy the message. Opinions, conclusions and other
information in this message that do not relate to official business of Mascon
shall be understood to be neither given nor endorsed by Mascon. Any information
contained in this email, when addressed to Mascon clients is subject to the
terms and conditions in governing client contract.
Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we
can not guarantee that any email or attachment is free from computer viruses
and you are strongly advised to undertake your own anti-virus precautions.
Mascon grants no warranties regarding performance, use or quality of any e-mail
or attachment and undertakes no liability for loss or damage, howsoever caused.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
