<div dir="ltr"><div><div><div><div><div>Hello,<br><br></div>I have the same case, a channel is being added to bridge.<br></div>But there is a difference that REINVITE happens only for outbound channels,<br></div>inbound channels added to the bridge don't receive any REINVITE.<br><br></div>To answer Joshua's question, below is the SIP message for INVITE and REINVITE,<br></div><div>please note that my messages are going through a proxy:<br><b><br></b></div><div><b>Initial INVITE</b><br></div><div><div style="margin-left:40px">INVITE sip:voxconf@x.x.x.x SIP/2.0
<br>Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK2b81de7a
<br>Max-Forwards: 70
<br>From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as4c1adfa5
<br>To: <sip:demo@x.x.x.x>
<br>Contact: <sip:anonymous@x.x.x.x:5060>
<br>Call-ID: <a href="http://57ea163b2649c51c0947484a59f01200@37.139.25.109:5060">57ea163b2649c51c0947484a59f01200@37.139.25.109:5060</a>
<br>CSeq: 102 INVITE
<br>User-Agent: Vox Conf
<br>Date: Tue, 26 Apr 2016 14:14:27 GMT
<br>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
<br>Supported: replaces, timer
<br>X-Remote-URI: sip:demo@x.x.x.x<br>Content-Type: application/sdp
<br>Content-Length: 263<br> <br>v=0
<br>o=root 136531202 136531202 IN IP4<b> 1.2.3.4</b><br>s=session
<br>c=IN IP4 37.139.25.109
<br>t=0 0
<br>m=audio 18518 RTP/AVP 8 0 101
<br>a=rtpmap:8 PCMA/8000
<br>a=rtpmap:0 PCMU/8000
<br>a=rtpmap:101 telephone-event/8000
<br>a=fmtp:101 0-16
<br>a=ptime:20
<br>a=maxptime:150
<br>a=sendrecv<br><br><br><br></div><b>REINVITE</b>:<br><br><div style="margin-left:40px">INVITE sip:x.x.x.x:5060 SIP/2.0
<br>Via: SIP/2.0/UDP x.x.x;x:5060;branch=z9hG4bK0fb60baf
<br>Route: <sip:x.x.x.x;lr>
<br>Max-Forwards: 70
<br>From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as4c1adfa5
<br>To: <sip:demo@x.x.x.x>;tag=69838245_85ff77e7_57a5b08a_f806b6dc
<br>Contact: <sip:anonymous@x.x.x.x:5060>
<br>Call-ID: <a href="http://57ea163b2649c51c0947484a59f01200@37.139.25.109:5060">57ea163b2649c51c0947484a59f01200@37.139.25.109:5060</a>
<br>CSeq: 103 INVITE
<br>User-Agent: Vox Conf
<br>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
<br>Supported: replaces, timer
<br><b>Remote-Party-ID</b>: "3225883116" <sip:3225883116@anonymous.invalid>;party=calling;privacy=off;screen=no
<br>Content-Type: application/sdp
<br>Content-Length: 263
<br> <br>v=0
<br>o=root 136531202 136531203 IN IP4 <b>1.2.3.4</b><br>s=session
<br>c=IN IP4 <b>1.2.3.4</b><br>t=0 0
<br>m=audio 18518 RTP/AVP 8 0 101
<br>a=rtpmap:8 PCMA/8000
<br>a=rtpmap:0 PCMU/8000
<br>a=rtpmap:101 telephone-event/8000
<br>a=fmtp:101 0-16
<br>a=ptime:20
<br>a=maxptime:150
<br>a=sendrecv<br></div><br></div><div>As you can note that, SIP signalling and SDP look almost exactly the same, Asterisk has added a Remote-Party-ID header<br></div><div>in the REINVITE for some reason and has updated the 'SDP' version in o line in the REINVITE.<br></div><div>I would ideally like to turn off these REINVITEs, some vendors may not too happy with it.<br><br></div><div>Regards,<br></div><div>Nitesh<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 27, 2016 at 4:34 AM, Kirill Marchuk <span dir="ltr"><<a href="mailto:62mkv@mail.ru" target="_blank">62mkv@mail.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi<br>
<br>
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)<br>
<br>
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) <br>
<br>
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. <br>
<br>
Kirill<br>
<br>
<div>26.04.2016 21:57, Nitesh Bansal пишет:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi,<br>
<br>
</div>
c-line in SDP remains the same, only SDP version in the
o-line changes.<br>
</div>
<br>
</div>
<div>Thanks,<br>
</div>
Nitesh<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Apr 26, 2016 at 4:45 PM, Joshua
Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Nitesh Bansal wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I'm building an ARI based conference with Asterisk 13.<br>
<br>
Scenario:<br>
Peer A dials into Asterisk, mixing bridge is created and
channel 1 put<br>
into the bridge.<br>
Asterisk is also told to initiate call to a recording
server, so<br>
recording server is<br>
also added into the bridge.<br>
I have noticed that after the initial INVITE completes
with the<br>
Recording Server,<br>
Asterisk is doing a REINVITE towards Recording server,
this REINVITE has the<br>
same media IP, media port though SDP version number
increases.<br>
<br>
I'm really curious why is Asterisk sending this REINVITE
on the outbound<br>
leg to<br>
the Recording server.<br>
Any logical rational for doing that?<br>
</blockquote>
<br>
</span>
Is it updating connected line information?<span><font color="#888888"><br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
Check us out at: <a href="http://www.digium.com" rel="noreferrer" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" rel="noreferrer" target="_blank"></a><a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank"></a><a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</font></span></blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
</div></div></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>