[Blink] Digest user
Adrian Georgescu
ag at ag-projects.com
Fri Apr 30 10:08:37 CEST 2010
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
>
More information about the Blink
mailing list