Hey Vynkat
For the branch id section 8.1.1.7 states this
"a CANCEL request
will have the same value of the branch parameter as the request it
cancels."
As for other things I think route in cancel should be same as route in
the request being cancelled.
Ashish Kumar Balyan
Continous Computing
[EMAIL PROTECTED] wrote:
Thanks!!
Are there any other parameters which also needs to
removed/added/updated while sending CANCEL for INVITE message.
Regards
-venkat
[EMAIL PROTECTED] wrote:
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.
Ah, your problem is the branch ID, you are having a branch ID which
is different from that of the INVITE you want to CANCEL.
While constructing the CANCEL, ensure that you have the same branch
ID as that of the INVITE you want to cancel. Branch ID is the main
key for transaction matching. Once UAC (caller B in your case) gets
the CANCEL, it cannot find any matching transaction and hence UAC
sends 481 back. If you send the same branch ID as that of the INVITE
you want to cancel, transaction matching should be successful and you
should get 200 OK for the CANCEL message.
Refer RFC 3261 : As discussed below, a CANCEL request will have the
same value of the branch parameter as the request it cancels.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
Thanks & Regards
Monica Ingudam (Mail: [EMAIL PROTECTED])
Signal Engineer
AOL Dulles
_______________________________________________
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
