[Blink] Digest user
Adrian Georgescu
ag at ag-projects.com
Fri Apr 30 15:41:05 CEST 2010
Thanks for the link!
Adrian
On Fri, 2010-04-30 at 22:36 +0930, Malcolm Caldwell wrote:
> Hi,
>
>
> Doing some more digging, shouldn't this type of INVITE be fixed
> already?
>
>
> http://trac.pjsip.org/repos/ticket/339
>
>
> http://osdir.com/ml/voip.pjsip/2007-06/msg00194.html
>
>
>
>
> Malcolm Caldwell
>
> On 30/04/2010, at 18:04, "Adrian Georgescu" <ag at ag-projects.com>
> wrote:
>
>
>
> > Well what I believe is less relevant.
> >
> > To see your problem solved you must see that:
> >
> > 1. Is supported in PJSIP
> > 2. Is supported in SIP SIMPLE client SDK
> >
> > PJSIP does accept patches and we do too, but I remember having a
> > similar discussion long time ago that ended up in the same place.
> > The
> > chance of implementing this functionality in PJSIP is very low
> > unless
> > some external party provides a patch and maintains it.
> >
> > Adrian
> >
> > On Apr 30, 2010, at 10:18 AM, Malcolm Caldwell wrote:
> >
> > > 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
> > >
> > >
> > > _______________________________________________
> > > Blink mailing list
> > > Blink at lists.ag-projects.com
> > > http://lists.ag-projects.com/mailman/listinfo/blink
> >
> > _______________________________________________
> > Blink mailing list
> > Blink at lists.ag-projects.com
> > http://lists.ag-projects.com/mailman/listinfo/blink
> >
> >
> >
> _______________________________________________
> Blink mailing list
> Blink at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo/blink
More information about the Blink
mailing list