On 1/25/13 7:40 AM, Dmitry Akindinov wrote:
> Hello,
>
> On 25.01.2013 16:22, Yaswanth Raparti wrote:
>> Hi Brett,
>>
>> Actually, I gave some random URI to hide the original uri. The original SIP
>> URI does not have any '%' . It was encoded though.
>
> If the Contact URI is syntactically correct and the proxy has inserted
> itself as the Record-Route header, then you should not be concerned with
> the Contact URI value and meaning.
>
> If the proxy did not insert itself into the dialog path using
> Record-Route headers, then it has a problem.
You say "you should not be concerned". That depends on what you want to
do. It is true that such a setup will allow *this* dialog to continue.
But it won't support anything that needs the contact, like transfer, etc.
The caller is required to provide a globally routable contact. If the
"proxy" (actually it is an SBC) is replacing it, then it should be
replacing it with one that still has the globally routable property.
(Though it might not if it is trying to provide privacy and block
callbacks.)
Thanks,
Paul
>> *V YAswanth RAparti
>> B.E Electrical and Electronics.
>> *
>>
>>
>> On 25 January 2013 17:48, Brett Tate<[email protected]> wrote:
>>
>>>> Thus the encrypted contact is either serving the intended
>>>> purpose or the proxy may have a configuration or software
>>>> issue. Talk to the proxy vendor or service provider.
>>>
>>> Additionally if the provided Contact is accurate, the vendor is not
>>> properly escaping the sip-uri per RFC 3261.
>>>
>>> For instance, they did not escape the first '%'.
>>>
>>> Contact:<sip:3ijk$%^&*@12.13.14.15:5060;encoded-parm=F$%^GH.VFGT1@ert4
>>> #;ue-addr=pcsf-abcd.xyzgroup-000.example.com;transport=tcp>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
