I think the RFC is pretty clear on what the behavior should be. Here is the quote from sec. 22.2:
When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request. Since it is asking the UAC to increment the Cseq number, it is implicit that the Call-Id + from-tag must not change from the initial request. So the UAC side of your B2BUA needs to follow this rule too. Sanjay >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On >Behalf Of [EMAIL PROTECTED] >Sent: Wednesday, July 25, 2007 10:23 PM >To: Jeroen van Bemmel >Cc: sip-implementors@lists.cs.columbia.edu >Subject: Re: [Sip-implementors] B2BUA Problem when processing 401/407 > >Jeroen van Bemmel wrote: >> >> So the SHOULD covers not only the Call-ID, but also To and From >> headers. It is probably a SHOULD because there may be reasons that >> from or to headers would be different. The UAC has no valid >reason to >> use a different Call-ID (and in fact is probably using the >same one), >> it likely breaks because your B2BUA is not generating call-ids >> deterministically. >> >> You do not have to reuse the client side call-id, all you need to >> ensure is that whenever a client uses X your B2BUA generates >Y. A hash >> function over the call-id, or a fixed transformation (e.g. always >> replacing host part with B2BUA IP address with or without a prefix) >> will do the trick >> >The To and From is not changing in the case of the B2BUA. >Only the call-id. > >I am already using a similar mechanism as you have mentioned >here. And yes the far-end UAC is using the same call-id. But >this will only be a >partial solution for me. In cases where the call fails-over >to another >route, we also make sure that the call-id is unique for accounting >purposes. This is where the problem really gets nasty. Let's say >there are 3 available routes to reach a destination and they are >configured as fail-over (each route having their own dialing rules). >Assume the first two got a 503. The b2bua fails-over. When >trying the >third route, it got a 401. > >If you think it's a should only because the To or From headers >can be different, then why include the call-id in the group of >SHOULD in the first place? Why not a MUST for Call-ID and a >SHOULD for To and From? >I think this is a wrong interpretation. If there is "no >valid reason" >for a UAC to use a different call-id, then this should be >amended and put the call-id under a must and on SHOULD those >you think implementors could change with valid reasons. > >My real intention is not to really get advise on how to change >the B2BUA code behavior to comply to the recommended behavior. > In fact I can maintain the call-id for the retry by simply >allowing the B2BUA session to linger at a lifespan of Timer B >after sending the 401/407 to make sure it can catch the >re-send and use the same states it had previously when the >call was challenged. > >My real intention is to get advice from implementors on how to >treat a SHOULD if ever I see the reason to take advantage of >it again in the >future. Re-quoting item 3 in 2119 > >3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > >My interpretation of this statement in reference to the SHOULD >in paragraph 7 of 8.1.3.5 of 3261 is that I as an implementor, >with extra care, is given a room for changing any of the >headers mentioned (as long as I do not break any other rules >in 3261 when doing so). This is not only in the point of view >of a UAC but of the UAS as well. I as an implementor, I >should see to it that since 3261 explicitly categorized an >item as a SHOULD, to not be stricter and enforce the SHOULD >item as a MUST in my server transactions. > >I agree that I might step on real world implementation which >uses these headers as a basis for proper operation and while >quite often break. In fact I already did, that's why I >started this thread. I will most probably change my code but >it would really be good to get views of co-implementors what >really is the correct interpretation here setting aside >accepted norms in current real-world implementations. > >Joegen > > > >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@lists.cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
