[Blink] Digest user

Fri Apr 30 10:18:52 CEST 2010

Adrian,

I really thing you are attributing a motive to the vendor which is unlikely.

I would be highly surprised if the vendor had decided to do this type of
INVITE just to limit which phones work with their PBX.

> From: Adrian Georgescu <ag at ag-projects.com>
> Reply-To: <blink at lists.ag-projects.com>
> Date: Fri, 30 Apr 2010 10:08:37 +0200
> To: Emil Ivov <emcho at sip-communicator.org>
> Cc: <blink at lists.ag-projects.com>
> Subject: Re: [Blink] Digest user
> 
> Hi Emil,

Indeed, that INVITE is valid RFC wise. But think about it more in a
> 
wider context. This behaviour expects the other end-points to do what  
is
> described (and convoluted) but in practice this does not happen  
with the
> majority of the SIP User Agents in the Internet world, Blink  
included in
> this case, that do negotiate the SDP starting with the  
first invite and not
> later.

While having SDP in the original INVITE will work with any User Agent
> 
on the planet, the opposite is not true, so this behaviour should be
> 
avoided because it leads inexorably to interoperability issues.

Being RFC
> correct does not also mean is also a clever thing to do  
unless you are a
> proprietary vendor that sale both the PBX and the  
phones like Cisco in this
> case. Most of the proprietary vendors do  
exactly this, they use the
> standards in their own tweaked way in order  
to sell more devices that
> complies with their solution and they do not  
care for generic
> interoperability with other implementations. Is  
actually a selling point for
> them to do this.

The actual technical reason is that PJSIP stack requires the
> presence  
of an SDP in the original Invite and I do not blame them for this
> 
design, It makes not sense for me to have INVITE with media  
description
> either.

In this case Blink will not work but it explicitly rejects the call
> 
with 488, which is also correct because it was designed to required  
SDP in
> the first INVITE.

Adrian

On Apr 30, 2010, at 9:32 AM, Emil Ivov wrote:

>
> Hey folks,
>
> (inline)
>
> На 30.04.10 08:47, Adrian Georgescu написа:
>>
>>
> On Apr 30, 2010, at 1:51 AM, Malcolm Caldwell wrote:
>>
>>> Hi Adrian,
>>>
>>>
> I now have the log from my work, although the packets are not the  
>>>
> same
>>> as I say yesterday.  (I wish I had saved them).  However, calls
> are
>>> not working, and this trace shows that:
>>>
>>> RECEIVED: Packet 19,
> +0:03:05.878643
>>> 2010-04-30 09:01:52.947054: SIP.SERVER.IP.ADDR:5060 -(SIP
> over  
>>> UDP)->
>>> MY.MAC.IP.ADDR:59181
>>> *INVITE
> sip:fcuzryxa at MY.MAC.IP.ADDR:59181 SIP/2.0
>>> *Date: Thu, 29 Apr 2010 23:31:54
> GMT
>>> Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,  
>>>
> REFER,
>>> SUBSCRIBE, NOTIFY
>>> From:
>>>
> <sip:YYYY at SIP.SERVER.IP.ADDR>;tag=94d7ad56-fdc6-40a9- 
>>>
> bd8e-772b8995b8b6-47099214
>>> Allow-Events: presence
>>> Supported:
> timer,resource-priority,replaces
>>> Min-SE:  1800
>>> Remote-Party-ID:
>>>
> <sip:YYYY at 138.80.6.4;x-cisco-callback- 
>>>
> number=YYYY>;party=calling;screen=yes;privacy=off
>>> Content-Length: 0
>>>
> User-Agent: Cisco-CUCM7.0
>>> To: <sip:XXXX at MY.MAC.IP.ADDR>
>>> Contact:
> <sip:YYYY at SIP.SERVER.IP.ADDR:5060>;video;audio
>>> Expires: 180
>>> Call-ID:
> 63b1d680-bda116ea-b7-406508a at SIP.SERVER.IP.ADDR
>>> Via: SIP/2.0/UDP
> SIP.SERVER.IP.ADDR:5060;branch=z9hG4bKc721379491
>>> CSeq: 101 INVITE
>>>
> Send-Info: conference
>>> Max-Forwards: 70
>>> Alert-Info:
> <file://Bellcore-dr1/>
>>
>> There is no SDP with any type of supported media
> in this Invite.
>>
>> You are using Blink against a non-standard compliant
> corporate PBX
>> solution that works only with approved phone devices by
> Cisco.
>>
>> What do you want to see happening except rejecting it?
>
> It's
> probably worth noting that 3261 does authorize empty INVITEs. In
> such cases
> you simply need to send an offer in the OK, and get the
> answer in the
> ACK.
>
> From 3261, 13.2.1:
>
>         The initial offer MUST be in either an
> INVITE or, if not  
> there,
>         in the first reliable non-failure
> message from the UAS back to
>         the UAC.  In this specification, that
> is the final 2xx
>         response.
>
> and then:
>
>         If the initial
> offer is in the first reliable non-failure
>         message from the UAS back
> to UAC, the answer MUST be in the
>         acknowledgement for that message
> (in this specification, ACK
>         for a 2xx response).
>
> Here's the
> whole thing (starting at the bottom):
>
> http://tools.ietf.org/html/rfc3261#page-79
>
> Cheers,
> Emil
>
>
>>
>>
> Adrian
>>
>>
>>
>> _______________________________________________
>> Blink
> mailing list
>> Blink at lists.ag-projects.com
>>
> http://lists.ag-projects.com/mailman/listinfo/blink
>
> -- 
> Emil Ivov, Ph.D.
> 67000 Strasbourg,
> Project Lead                                   France
>
> SIP Communicator
> emcho at sip-communicator.org                     PHONE:  
>
> +33.1.77.62.43.30
> http://sip-communicator.org                    FAX:    
>
> +33.1.77.62.47.31
>

_______________________________________________
Blink
> mailing 
> list
Blink at lists.ag-projects.com
http://lists.ag-projects.com/mailman/listinfo
> /blink