The top Via received by the UAS should never have a "received="
parameter irrespective of the topology.

Correct operation is like this:

1. UAC sends request with Via:UAC
2. proxy receives request
3. proxy adds "received=" parameter and then adds a top Via for itself
4. proxy sends request with
   Via:Proxy, Via:UAC;received=whatever

The first Via (top Via) recevied by UAS would not have a "received=" parameter.

Now if (at step 3), the proxy adds a "received=" into the new top Via,
then this is illegal.  Anyway, what purpose would it serve?

Anyway, if the proxy wants to store non-standard information in the
Via header then it should store it opaquely in the newly-inserted
top Via's branch parameter.  Then it won't break interop with any
other SIP entities.


Regards,

Attila



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Madhav 
Bhamidipati
Sent: 26 March 2008 12:56
To: Iñaki Baz Castillo
Cc: [email protected]
Subject: Re: [Sip-implementors] What to do if a UAS receives a request withVia 
- "received" param?

Hi Attila,

I wonder if the following topology is  invalid, in which case the forwarding 
stateless proxy can as well put the received information in Via header.

If UAS erases the received information  then it would be impossible for  the 
proxy would send response to UAC.


        UAC       NAT1    Proxy  NAT2   UAS
              |         |         |            |             |
              |         |         |            |             |
              |         |         |            |             |
              |         |         |            |             |
              |         |         |            |             |
              |         |         |            |             |

Madhav

On Wed, Mar 26, 2008 at 5:27 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]>
wrote:

> El Wednesday 26 March 2008 12:51:01 Nitin Arora escribió:
> > ya you are right I misinterpreted the question and answered in 
> > hurry.
> > but Via is added by UAC, isn't it?
>
> In fact I'm just reading RFC 3261 and trying to solve my doubts, it 
> wasn't a real case :)
>
> --
> Iñaki Baz Castillo
> [EMAIL PROTECTED]
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to