Ok, I got it.
Thanks for your support.
Thanks and Regards,
Amith
-Original Message-
From: Brett Tate [mailto:br...@broadsoft.com]
Sent: Tuesday, July 05, 2011 5:05 PM
To: Amith R R; Sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Regarding Subscription Termination
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Simon Gregory
[si...@myphones.com]
If a UA sends a REGISTER with say a@b.c: as a contact (binding) would it
ever be conceivable that a r
please ignore
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> Has anyone ever seen the contact of a 200 OK return URI
> info about the proxy / registrar itself?
> i.e. contact in 200 OK = a@regip:regport
Yes; it can happen if SBC changes Contact within REGISTER before sending to
registrar and subsequently did not change it back within the 200 response(s
2011/7/5 Simon Gregory :
>
> I was under the impression that RFC3261 Sect 10.3, subsect 8 makes it
> explicit that a proxy / registrar should return (in the contact) the
> bindings (typically 1 in my simple scenario) that is basically a reflection
> of the contact sent in the original REGISTER.
Ye
If a UA sends a REGISTER with say a@b.c: as a contact (binding) would it
ever be conceivable that a registrar would return anything other than that
binding in a 200 OK (I am assuming here that this UA is only registering
once).
More specifically,
Has anyone ever seen the contact of a 2
Thanks Gents,
I'm sorry my terminology has caused confusion. However The responses received
have clarified things for me.
Seems the vendor is not in violation of the standard, just not implementing the
solution well. I'll try another tack to get the way they handle the codec
negotiation modifie
On Tue, Jul 5, 2011 at 1:32 PM, Iñaki Baz Castillo wrote:
> 2011/7/5 Brez Borland :
> > I think this is a complete misinterpretation of the nature of
> Record-Route
> > mechanism. As opposed to RURI, Record-Route gives a one-hop behavior, and
> > indicating SIPS scheme, without transport paramete
2011/7/5 Brez Borland :
> I think this is a complete misinterpretation of the nature of Record-Route
> mechanism. As opposed to RURI, Record-Route gives a one-hop behavior, and
> indicating SIPS scheme, without transport parameter, is enough.
Right.
--
Iñaki Baz Castillo
__
On Tue, Jul 5, 2011 at 12:58 PM, Iñaki Baz Castillo wrote:
> 2011/7/5 Brez Borland :
> > Have a look at:
> > pjsip/src/pjsua-lib/pjsua_call.c: get_secure_level();
> >
> > It seems to me that PJSIP does not support SIPS scheme in Record-Route.
> That
> > said, you have to put SIP and "transport=tl
On Tue, Jul 5, 2011 at 1:14 PM, Brez Borland wrote:
> On Tue, Jul 5, 2011 at 1:01 PM, Iñaki Baz Castillo wrote:
>
>> 2011/7/5 Iñaki Baz Castillo :
>> > 2011/7/5 Brez Borland :
>> >> A very interesting thing I have just encountered, rfc5603 Section 3.1.4
>> >> says:
>> >>
>> >> The transport=tls
On Tue, Jul 5, 2011 at 1:01 PM, Iñaki Baz Castillo wrote:
> 2011/7/5 Iñaki Baz Castillo :
> > 2011/7/5 Brez Borland :
> >> A very interesting thing I have just encountered, rfc5603 Section 3.1.4
> >> says:
> >>
> >> The transport=tls parameter has never been defined in an RFC, but only
> in
> >>
2011/7/5 Iñaki Baz Castillo :
> But note that my case is a bit special as the initial INVITE arrives
> via TLS to the proxy, but does not contain a sips schema no where. So
> maybe in this case (and just in this case) the URI in the Record-Route
> should not contain a sips: schema and instead conta
2011/7/5 Iñaki Baz Castillo :
> 2011/7/5 Brez Borland :
>> A very interesting thing I have just encountered, rfc5603 Section 3.1.4
>> says:
>>
>> The transport=tls parameter has never been defined in an RFC, but only in
>> some of the Internet drafts between [RFC2543] and [RFC3261].
>>
>> So they c
2011/7/5 Brez Borland :
> A very interesting thing I have just encountered, rfc5603 Section 3.1.4
> says:
>
> The transport=tls parameter has never been defined in an RFC, but only in
> some of the Internet drafts between [RFC2543] and [RFC3261].
>
> So they couldn't really deprecate it, or restric
2011/7/5 Brez Borland :
> Have a look at:
> pjsip/src/pjsua-lib/pjsua_call.c: get_secure_level();
>
> It seems to me that PJSIP does not support SIPS scheme in Record-Route. That
> said, you have to put SIP and "transport=tls" when writing Record-Route.
So UGLY
Thanks for pointing it out.
--
A very interesting thing I have just encountered, rfc5603 Section 3.1.4
says:
The transport=tls parameter has never been defined in an RFC, but only in
some of the Internet drafts between [RFC2543] and [RFC3261].
So they couldn't really deprecate it, or restrict it, cause it never really
existed.
Have a look at:
pjsip/src/pjsua-lib/pjsua_call.c: get_secure_level();
It seems to me that PJSIP does not support SIPS scheme in Record-Route. That
said, you have to put SIP and "transport=tls" when writing Record-Route.
Regards,
Brez
On Tue, Jul 5, 2011 at 12:16 PM, Brez Borland wrote:
> Hi
> As per the below description, AS has to send NOTIFY
> and Core network has to reject it in order to cancel
> the subscription.
Those are not the only ways to terminate the subscription.
If the NOTIFY is to terminate the subscription, the transferor does not have to
reject the NOTIFY.
I
Hi Inaki,
On Tue, Jul 5, 2011 at 10:43 AM, Iñaki Baz Castillo wrote:
> Hi, I'm experimenting a problem with a client (PJSIP) connecting to a
> proxy via TLS:
>
> - The client uses "sip:" scheme in INVITE headers and "sip:" with
> ";transport=tls" in Contact header. It is valid according to some
Hi, I'm experimenting a problem with a client (PJSIP) connecting to a
proxy via TLS:
- The client uses "sip:" scheme in INVITE headers and "sip:" with
";transport=tls" in Contact header. It is valid according to some RFC.
- The proxy routes the INVITE via UDP and adds a Record-Route like this:
21 matches
Mail list logo
