Hi all!
We implement a SIP User Agent, and have a problem.
When we try to send REGISTER or INVITE message to FWD (fwdnat.pulver.com:5082),
the server reponds with a message that doesn't contain branch parameter in Via field,
while we had one in our request. So, we cannot map the response to the sent request.
Is this correct behaviour, and if yes, what's the reason for that?
Or if it's not quite correct, please let us know how can we avoid this situation.
By the way, we have no such problem with fwd.pulver.com:5060.
Here are the excerpts from new and old SIP RFCs about this issue and message logs.
Thanks in advance.
Simon.
***************************************************************************
RFC2543
10 Behavior of SIP Clients and Servers
10.1.2 Responses
......
Responses are mapped to requests by the matching To, From, Call-ID,
CSeq headers and the branch parameter of the first Via header.
Responses terminate request retransmissions even if they have Via
headers that cause them to be delivered to an upstream client.
.......
***************************************************************************
RFC3261
8.1 UAC Behavior
8.1.1 Generating the Request
8.1.1.7 Via
When the UAC creates a request, it MUST insert a Via into that
request. The protocol name and protocol version in the header field
MUST be SIP and 2.0, respectively. The Via header field value MUST
contain a branch parameter. This parameter is used to identify the
transaction created by that request. This parameter is used by both
the client and the server.
The branch parameter value MUST be unique across space and time for
all requests sent by the UA. The exceptions to this rule are CANCEL
and ACK for non-2xx responses. As discussed below, a CANCEL request
will have the same value of the branch parameter as the request it
cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx
response will also have the same branch ID as the INVITE whose
response it acknowledges.
The uniqueness property of the branch ID parameter, to
facilitate
its use as a transaction ID, was not part of RFC 2543.
The branch ID inserted by an element compliant with this
specification MUST always begin with the characters "z9hG4bK". These
7 characters are used as a magic cookie (7 is deemed sufficient to
ensure that an older RFC 2543 implementation would not pick such a
value), so that servers receiving the request can determine that the
branch ID was constructed in the fashion described by this
specification (that is, globally unique). Beyond this requirement,
the precise format of the branch token is implementation-defined.
17 Transactions
17.1 Client Transaction
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.
***************************************************************************
REGISTER sip:fwd.pulver.com:5060 SIP/2.0
Via: SIP/2.0/UDP
212.126.211.246:5076;branch=z9hG4bKEPSVBUS7aeffbbf2-97d9da-8c19-0cfa0a01e3
To: <sip:[EMAIL PROTECTED]>
From: <sip:[EMAIL PROTECTED]>;tag=760b9a5c3-bed9ca-c822-bac9cb38d7
CSeq: 1 REGISTER
Call-ID: [EMAIL PROTECTED]
Contact: <sip:[EMAIL PROTECTED]:5076>;expires=3600
User-Agent: EPYGI QUADRO SIP-UA/1.1
Max-Forwards: 70
Content-Length: 0
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 212.126.211.246:5076
To: <sip:[EMAIL PROTECTED]>;tag=b27e1a1d33761e85846fc98f5f3a7e58.65e2
From: <sip:[EMAIL PROTECTED]>;tag=760b9a5c3-bed9ca-c822-bac9cb38d7
CSeq: 1 REGISTER
Call-ID: [EMAIL PROTECTED]
WWW-Authenticate: Digest realm="fwd.pulver.com",
nonce="3f8aa02ef11a70b1a98d58023703a623077d1710"
Server: Free World Dialup (0.8.11rc3 (i386/linux))
Content-Length: 0
***************************************************************************************************
INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
Via: SIP/2.0/UDP
212.126.211.246:5076;branch=z9hG4bKEPSVBUS00973059f-c5b328-245b-1131b808e8
To: <sip:[EMAIL PROTECTED]>
From: <sip:[EMAIL PROTECTED]>;tag=fb495a33e-bb199e-9854-2044ca4984
CSeq: 384 INVITE
Call-ID: [EMAIL PROTECTED]
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Contact: <sip:[EMAIL PROTECTED]:5076>
Content-Type: application/sdp
User-Agent: EPYGI QUADRO SIP-UA/1.1
Max-Forwards: 70
Content-Length: 256
v=0
o=17184 846930886422355 1846930886422355 IN IP4 212.126.211.246
s=EPYGI FIAD User Agent/1.0
c=IN IP4 212.126.211.246
t=0 0
m=audio 6080 RTP/AVP 0 8 2 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:18 G729a/8000
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 212.126.211.246:5076
t: <sip:[EMAIL PROTECTED]>;tag=b27e1a1d33761e85846fc98f5f3a7e58.65e2
f: <sip:[EMAIL PROTECTED]>;tag=fb495a33e-bb199e-9854-2044ca4984
CSeq: 384 INVITE
i: [EMAIL PROTECTED]
Proxy-Authenticate: Digest realm="fwd.pulver.com",
nonce="3f8aa0bfa811a1c29a5e6a251b6eb0465863ff57"
Server: Free World Dialup (0.8.11rc3 (i386/linux))
Content-Length: 0
***************************************************************************************************
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
