Has anyone successfully implementated a client that works with MS LCS/OCS or
a server that works with MS Messenger/Office Communicator?
I'm having a problem with verification and composition of signatures.
According to MS documentation of its SIP extensions :-
The client MUST use the following va
El Viernes, 24 de Octubre de 2008, Alex Balashov escribió:
> > Well, not totally needed. A UA could construct a REGISTER like this:
> >
> > REGISTER sip:[EMAIL PROTECTED] SIP/2.0
> >
> > and sent it to host:15060.
> >
> > For example Twinkle does it if you set the registrar in a port different
>
Iñaki Baz Castillo wrote:
> El Viernes, 24 de Octubre de 2008, Vikram Chhibber escribió:
>> I think we are digressing from the original query. The question is not
>> about routing of tel url. The query is why the public identities in
>> From and To header can not be tel for SUBSCRIBE. A better ex
On Fri, Oct 24, 2008 at 7:15 PM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
> I'd start by asking the author of 3265 if he thinks its a bug.
> (That isn't definitive, but its a good start.)
> If so, it might just be recorded as a bug and fixed the next time an
> update is done to 3265.
>
> If it is mo
I'd start by asking the author of 3265 if he thinks its a bug.
(That isn't definitive, but its a good start.)
If so, it might just be recorded as a bug and fixed the next time an
update is done to 3265.
If it is more controversial, then it will be a pain in the ass.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> El Viernes, 24 de Octubre de 2008, [EMAIL PROTECTED] escribió:
>> sip:[EMAIL PROTECTED]:5060
>> sip:[EMAIL PROTECTED]:15060
>> sip:[EMAIL PROTECTED]:25060
>> sip:[EMAIL PROTECTED]:35060
>>
>> In that case, the request-URI of the REGISTER n
El Viernes, 24 de Octubre de 2008, [EMAIL PROTECTED] escribió:
> sip:[EMAIL PROTECTED]:5060
> sip:[EMAIL PROTECTED]:15060
> sip:[EMAIL PROTECTED]:25060
> sip:[EMAIL PROTECTED]:35060
>
> In that case, the request-URI of the REGISTER needs to contain the
> proper port
El Viernes, 24 de Octubre de 2008, Stephen Paterson escribió:
> Hi all,
>
> Is it valid for a REGISTER request to contain a port parameter?
> e.g. REGISTER sip:example.com:4060
>
> I can't see anything in RFC 3261 that explicitly bans it. userinfo and @
> yes, but not port. I may be looking in the
From: "Stephen Paterson" <[EMAIL PROTECTED]>
Is it valid for a REGISTER request to contain a port parameter?
e.g. REGISTER sip:example.com:4060
The request-URI should be the hostport part of the address of record
to which you are registering the contact. In almost all cases, the
addres
I would not send a subscribe for tel+ URI, this would open pandora's
box with a multitude of possibilities that end in the same wrong place
every time.
Keep SIP simple.
In you case the best way is to perform an ENUM lookup before
subscribing, resolve the number into a SIP URI and subscribe
No purpose that I can think of.
Our stack adds it and this has worked fine for ages with many registrars
but now we've come across one that just ignores the whole request
because of it. Seems a little harsh.
The question is, is it valid?
Cheers
Steve
-Original Message-
From: Alex Balashov
What purpose would it serve to have a port?
You can send the REGISTER request to an alternate port besides UDP 5060
without including that port in the domain part of the RURI.
Stephen Paterson wrote:
> Hi all,
>
> Is it valid for a REGISTER request to contain a port parameter?
> e.g. REGISTER
Hi all,
Is it valid for a REGISTER request to contain a port parameter?
e.g. REGISTER sip:example.com:4060
I can't see anything in RFC 3261 that explicitly bans it. userinfo and @
yes, but not port. I may be looking in the wrong place.
It may be that it is implicitly banned by 10.2 but I'm not
El Viernes, 24 de Octubre de 2008, Vikram Chhibber escribió:
> I think we are digressing from the original query. The question is not
> about routing of tel url. The query is why the public identities in
> From and To header can not be tel for SUBSCRIBE. A better explanation
> only the RFC authors
I think we are digressing from the original query. The question is not
about routing of tel url. The query is why the public identities in
>From and To header can not be tel for SUBSCRIBE. A better explanation
only the RFC authors can provide.
On Fri, Oct 24, 2008 at 7:52 PM, Klaus Darilion
<[EMAI
Vikram Chhibber schrieb:
> IMO "pres" uri is meant for presentity/watchers participants for
> "presence" and related event packages.
> "sip" scheme is more generic and may include "sip protocol"
> participants including call and "presence".
> All these schemes are meant for IP domain. TEL scheme
Paul Kyzivat schrieb:
>
> Iñaki Baz Castillo wrote:
>> 2008/10/22 Iñaki Baz Castillo <[EMAIL PROTECTED]>:
>>> Hi, SIP Presence Event Package RFC( 3856 ) says that From and To of a
>>> SUBSCRIBE cannot be a TEL URI:
>>>
>>> Section 5.
>>>
>>> SUBSCRIBE messages also contain logical identifie
Scott Lawrence schrieb:
> Whether or not to forward a SIP request that is not for your domain
> depends on your deployment model and whether or not you want to support
> end-to-end SIP calling. If you want to be able to support end-to-end
> SIP, that implies that your users can use real SIP URLs
You are asking two different questions. More inline.
Subbu Rajendran wrote:
> Hi,
> SIP RFC 2543 uses c=0.0.0.0 method to put a call on hold. RFC 3264 has
> introduced a=sendonly/recvonly/inactive/sendrecv attributes that can be used
> put media to one way, hold and 2-way. However what should be t
Iñaki Baz Castillo wrote:
> 2008/10/22 Iñaki Baz Castillo <[EMAIL PROTECTED]>:
>> Hi, SIP Presence Event Package RFC( 3856 ) says that From and To of a
>> SUBSCRIBE cannot be a TEL URI:
>>
>> Section 5.
>>
>> SUBSCRIBE messages also contain logical identifiers that define the
>> originat
Hi,
I think the first preference must be a=sendonly followed by c=0.0.0.0 which is
just the
backward compatibility. This will also ensure the cases where in the given SDP,
some
m lines are on hold while some are not.
Regards,
Somesh S Shanbhag
M G L Bangalore
-Original Message-
From
IMO "pres" uri is meant for presentity/watchers participants for
"presence" and related event packages.
"sip" scheme is more generic and may include "sip protocol"
participants including call and "presence".
All these schemes are meant for IP domain. TEL scheme is defined to
accommodate E.164 numbe
Hi,
SIP RFC 2543 uses c=0.0.0.0 method to put a call on hold. RFC 3264 has
introduced a=sendonly/recvonly/inactive/sendrecv attributes that can be used
put media to one way, hold and 2-way. However what should be the precedence
to be followed? Consider the case below
A Re-INVITE with SDP
v=0
o=use
2008/10/22 Iñaki Baz Castillo <[EMAIL PROTECTED]>:
> Hi, SIP Presence Event Package RFC( 3856 ) says that From and To of a
> SUBSCRIBE cannot be a TEL URI:
>
> Section 5.
>
> SUBSCRIBE messages also contain logical identifiers that define the
> originator and recipient of the subscription
24 matches
Mail list logo
