Hi, >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?
It is wrong behaviour. >Or if it's not quite correct, please let us know how can we >avoid this situation. You could use the RFC2543 way of transaction mapping. But, of course you should not have to do that - the remote server should work correctly. Regards, Christer Holmberg Ericsson Finland > > 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-8c1 > 9-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-245 > b-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 > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
