[asterisk-dev] Asterisk REINVITE

Wed Apr 27 04:21:33 CDT 2016

Hello,

I have the same case, a channel is being added to bridge.
But there is a difference that REINVITE happens only for outbound channels,
inbound channels added to the bridge don't receive any REINVITE.

To answer Joshua's question, below is the SIP message for INVITE and
REINVITE,
please note that my messages are going through a proxy:

*Initial INVITE*
INVITE sip:voxconf at x.x.x.x SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK2b81de7a
Max-Forwards: 70
From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=as4c1adfa5
To: <sip:demo at x.x.x.x>
Contact: <sip:anonymous at x.x.x.x:5060>
Call-ID: 57ea163b2649c51c0947484a59f01200 at 37.139.25.109:5060
CSeq: 102 INVITE
User-Agent: Vox Conf
Date: Tue, 26 Apr 2016 14:14:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
X-Remote-URI: sip:demo at x.x.x.x
Content-Type: application/sdp
Content-Length: 263

v=0
o=root 136531202 136531202 IN IP4* 1.2.3.4*
s=session
c=IN IP4 37.139.25.109
t=0 0
m=audio 18518 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

*REINVITE*:

INVITE sip:x.x.x.x:5060 SIP/2.0
Via: SIP/2.0/UDP x.x.x;x:5060;branch=z9hG4bK0fb60baf
Route: <sip:x.x.x.x;lr>
Max-Forwards: 70
From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=as4c1adfa5
To: <sip:demo at x.x.x.x>;tag=69838245_85ff77e7_57a5b08a_f806b6dc
Contact: <sip:anonymous at x.x.x.x:5060>
Call-ID: 57ea163b2649c51c0947484a59f01200 at 37.139.25.109:5060
CSeq: 103 INVITE
User-Agent: Vox Conf
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
*Remote-Party-ID*: "3225883116"
<sip:3225883116 at anonymous.invalid>;party=calling;privacy=off;screen=no

Content-Type: application/sdp
Content-Length: 263

v=0
o=root 136531202 136531203 IN IP4 *1.2.3.4*
s=session
c=IN IP4 *1.2.3.4*
t=0 0
m=audio 18518 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

As you can note that, SIP signalling and SDP look almost exactly the same,
Asterisk has added a Remote-Party-ID header
in the REINVITE for some reason and has updated the 'SDP' version in o line
in the REINVITE.
I would ideally like to turn off these REINVITEs, some vendors may not too
happy with it.

Regards,
Nitesh

On Wed, Apr 27, 2016 at 4:34 AM, Kirill Marchuk <62mkv at mail.ru> wrote:

> Hi
>
> I've seen exactly the same behaviour and even used gdb breakpoints to
> understand why is this happening (the only mention-worthy difference in
> SIP/SDP between INVITE and re-INVITE was the ;tag added to To: header)
>
> Unfortunately, I did not save the results, but if I remember correctly,
> that happened simply because a channel was added to a bridge, and bridge
> was calling "update_connectedline" function on every of the channels
> involved (including the newly added channel itself)
>
> That was the most basic case we did with ARI, so we were a little
> surprised of course, but somehow we've decided that this is "how ARI works"
> so we stopped further research on this.
>
> Kirill
>
> 26.04.2016 21:57, Nitesh Bansal пишет:
>
> Hi,
>
> c-line in SDP remains the same, only SDP version in the o-line changes.
>
> Thanks,
> Nitesh
>
> On Tue, Apr 26, 2016 at 4:45 PM, Joshua Colp <jcolp at digium.com> wrote:
>
>> Nitesh Bansal wrote:
>>
>>> Hello,
>>>
>>> I'm building an ARI based conference with Asterisk 13.
>>>
>>> Scenario:
>>> Peer A dials into Asterisk, mixing bridge is created and channel 1 put
>>> into the bridge.
>>> Asterisk is also told to initiate call to a recording server, so
>>> recording server is
>>> also added into the bridge.
>>> I have noticed that after the initial INVITE completes with the
>>> Recording Server,
>>> Asterisk is doing a REINVITE towards Recording server, this REINVITE has
>>> the
>>> same media  IP, media port though SDP version number increases.
>>>
>>> I'm really curious why is Asterisk sending this REINVITE on the outbound
>>> leg to
>>> the Recording server.
>>> Any logical rational for doing that?
>>>
>>
>> Is it updating connected line information?
>>
>> --
>> Joshua Colp
>> Digium, Inc. | Senior Software Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>> Check us out at: www.digium.com & <http://www.asterisk.org>
>> www.asterisk.org
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by <http://www.api-digital.com>
>> http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160427/576f58b4/attachment.html>