Anshuman,
You are right , that's where i have a doubt too. for the Via header
value for CANCEL and INVITE they differ in branch parameter value.Where
i dont know if that should be same.
What put me in doubt is , with CISCO MG it works!! but with pingtel is
doesn't.So not able to figure out the right way to construct CANCEL message.
Regards
-venkat
Anshuman Rawat wrote:
Tadkot,
I think the problem is here --> ".... and insert it own VIA header field
value."
Section 9.1 of RFC 3261 states that -
"A CANCEL constructed by a client MUST have only a single Via header
field value matching the top Via value in the request being cancelled."
I am not sure about the branch parameter though (but my guess is that
should be the same too).
Regards,
Anshuman S. Rawat
Software Group,
Conexant Systems India Private Ltd.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, November 18, 2005 5:26 PM
To: Sip-Implementors
Subject: [Sip-implementors] CANCEL message construction at proxy level
Hi All,
I am new to this mail grpu and SIP world :). I need some information
about how to construct the CANCEL message at the proxy level.
Scenario
1> Caller A sends INVITE message to PROXY
2> PROXY(stateful) send 100 trying to caller A and sends the INVITE
message to caller B
3> Caller A sends CANCEL message to PROXY to cancel the INVITE message
4> PROXY send 200 OK and 487 response back to Caller A and checks for
1xx response from caller B and construct the CANCEL message to send to
caller B
5> PROXY construct this message with same Request-URI, TO , FROM,
CALL-ID and Cseq number field values of the INVITE message send to
caller B and insert it own VIA header field value. the branch id is
different from the one which is sent in INVITE message to caller B.
5> But the CALLER B sends 481 Call/Transaction Does Not Exist message
back to PROXY.
NOTE: if the CALLER B is CISCO media gateway, then it accept CANCEL
message by sending 200 OK and 487 message, But if it is a Pingtel phone
then it sends 481.
Any clue why the behavior is different here.
Thanks and Regards
-venkat
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the
intended recipient. Any unauthorized review, use or distribution by others is strictly
prohibited. If you have received the message in error, please advise the sender by reply
email and delete the message. Thank you."
**********************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
