<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hmmm, according to your refs, none really apply to this situation.<br><br><h3 id="gmail-ManipulatingPartyIDInformation-CALLERIDdialplanfunction" style="margin-left:40px">CALLERID dialplan function</h3><p style="margin-left:40px">The
CALLERID function has been around for quite a while and its use is
straightforward. It is used to examine and alter the caller information
that came into the dialplan with the call. Then the call with it's
caller information passes on to the destination using the Dial() or
Queue() application.</p><p style="margin-left:40px">The CALLERID information is passed during the
initial call setup. However, depending on the channel technology, the
caller name may be delayed. Q.SIG is an example where the caller name
may be delayed so your dialplan may need to wait for it.</p><h3 id="gmail-ManipulatingPartyIDInformation-CONNECTEDLINEdialplanfunction" style="margin-left:40px">CONNECTEDLINE dialplan function</h3><p style="margin-left:40px">The
CONNECTEDLINE function does the opposite of the CALLERID function.
CONNECTEDLINE can be used to setup connected line information to be sent
when the call is answered. You can use it to send new connected line
information to the remote party on the channel when a call is
transferred. The CONNECTEDLINE information is passed when the call is
answered and when the call is transferred.</p><div style="margin-left:40px"> </div><div class="gmail-aui-message gmail-warning gmail-shadowed gmail-information-macro" style="margin-left:40px">
<span class="gmail-aui-icon gmail-icon-warning">Icon</span>
<div class="gmail-message-content">
<p>It is up to the channel technology to
determine when to act upon connected line updates before the call is
answered. ISDN will just store the updated information until the call is
answered. SIP will immediately update the caller with a Re-INVITE.</p>
</div>
</div><div style="margin-left:40px">
</div><p style="margin-left:40px">Since the connected line information can be sent while a call is
connected, you may need to prevent the channel driver from acting on a <strong>partial</strong> update. The 'i' option is used to inhibit the channel driver from sending the changed information immediately.</p><h3 id="gmail-ManipulatingPartyIDInformation-REDIRECTINGdialplanfunction"><br></h3><br><br> the callerid of the target phone is set in the pjsip channel driver config, not in my dialplan (the same as chan_sip):<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">And, my dialplan doesn't care about the callerid info for the phone you are dialing... in chan_sip, I get it via the 180 Ringing, but in pjsip, I am given useless information instead. I don't need it to change the sip exchanges to a re-invite, either. The phone is able to pick it up from the 180 Ringing just fine.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Here is the config for the endpoints, a little cut down:<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>[t12] ; Yealink T49G mac=00:15:65:...<br>type=endpoint<br>auth=t12<br>transport=transport-udp<br>aors=t12<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><snip><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">callerid="Steve" <101><br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[t13] ; Yealink T48G mac=00:15:65:...<br>type=endpoint<br>auth=t13<br>transport=transport-udp<br>aors=t13<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><snip><br>callerid="s2 test" <102><br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Since the config holds the callerids for each endpoint, I don't have any code to do lookups to get the callerid of the target. chan_sip has been fine providing it to the phone via the 180 Ringing...<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Right now, I'm running the exact same dialplan for chan_sip and pjsip. Are you telling me that I have to change the dialplan for pjsip? Can you give me a solid example of what I'd need to do in the dialplan to get the same effect? As a matter of fact, I run the two channel drivers on two different ports, and I have phones on pjsip, and phones on chan_sip at the same time...<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">murf<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 10:27 AM, Richard Mudgett <span dir="ltr"><<a href="mailto:rmudgett@digium.com" target="_blank">rmudgett@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, May 15, 2017 at 10:45 AM, Steve Murphy <span dir="ltr"><<a href="mailto:murf@parsetree.com" target="_blank">murf@parsetree.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Hello--<br><br></div><div style="font-family:arial,helvetica,sans-serif">I've got complaints that the phones are presenting the wrong info when making an outgoing call... instead of displaying the called party info, it's displaying the caller's info, which is highly uninteresting. I've been looking at the behavior with Yealink phones, but I'm told that ALL phones have the problem, and comparing with the sip channel driver.<br><br></div><div style="font-family:arial,helvetica,sans-serif">I'm working with asterisk (and pjsip) at version 13.15.0, so this is pretty much current behavior.<br><br></div><div style="font-family:arial,helvetica,sans-serif">I traced it down to the 180 Ringing message sent to the phone from Asterisk, in the course of making an outgoing call from the Yealink, in this case, to another extension on the same phone system. <br><br></div><div style="font-family:arial,helvetica,sans-serif">In the old chan_sip world, I see this:<br><br>[May 13 13:10:58] <--- Transmitting (NAT) to <a href="http://67.215.23.186:28762" target="_blank">67.215.23.186:28762</a> ---><br>[May 13 13:10:58] SIP/2.0 180 Ringing<br>[May 13 13:10:58] Via: SIP/2.0/UDP 192.168.134.126:5060;branch=z9<wbr>hG4bK1785363097;received=67.29<wbr>1.23.186;rport=28762<br>[May 13 13:10:58] From: "Steve Murphy" <<a href="http://sip:nvl19049@190.190.190.190:5060" target="_blank">sip:nvl19049@190.190.190.190:<wbr>5060</a>>;tag=2559859725<br>[May 13 13:10:58] To: <<a href="http://sip:767@190.190.190.190:5060" target="_blank">sip:767@190.190.190.190:5060</a>><wbr>;tag=as0a66b2c7<br>[May 13 13:10:58] Call-ID: <a href="mailto:0_762068959@192.168.134.126" target="_blank">0_762068959@192.168.134.126</a><br>[May 13 13:10:58] CSeq: 2 INVITE<br>[May 13 13:10:58] Server: nexVortex Inc Hosted 3.0 PBX<br>[May 13 13:10:58] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE<br>[May 13 13:10:58] Supported: replaces, timer<br>[May 13 13:10:58] Contact: <<a href="http://sip:767@190.190.190.190:5060" target="_blank">sip:767@190.190.190.190:5060</a>><br>[May 13 13:10:58] <span style="color:rgb(204,0,0)">Remote-Party-ID: "Shifting Sands" <<a href="mailto:sip%3A767@190.190.190.190" target="_blank">sip:767@190.190.190.190</a>>;part<wbr>y=called;privacy=off;screen=no</span><br>[May 13 13:10:58] Content-Length: 0<br>[May 13 13:10:58] <br><br></div><div style="font-family:arial,helvetica,sans-serif">Note, that Asterisk serves up callerid info from the target extension in this header, providing not only the number of the target extension, but the callerid NAME info, also, which is pretty nice!<br></div><div style="font-family:arial,helvetica,sans-serif"><br clear="all"></div><div>But, in the PJSIP world, I see this instead (on a different test system):<br><br>[May 13 08:21:59] <--- Transmitting SIP response (597 bytes) to UDP:<a href="http://192.168.134.102:5060" target="_blank">192.168.134.102:5060</a> ---><br>[May 13 08:21:59] SIP/2.0 180 Ringing<br>[May 13 08:21:59] Via: SIP/2.0/UDP 192.168.134.102:5060;rport=506<wbr>0;received=192.168.134.102;bra<wbr>nch=z9hG4bK1705376406<br>[May 13 08:21:59] Call-ID: <a href="mailto:0_1685072057@192.168.134.102" target="_blank">0_1685072057@192.168.134.102</a><br>[May 13 08:21:59] From: "Steve" <<a href="mailto:sip%3At12@192.168.134.227" target="_blank">sip:t12@192.168.134.227</a>>;tag=<wbr>3119644064<br>[May 13 08:21:59] To: <<a href="mailto:sip%3A102@192.168.134.227" target="_blank">sip:102@192.168.134.227</a>>;tag=<wbr>c7988cae-0380-49b4-84e6-0a03b6<wbr>56ab85<br>[May 13 08:21:59] CSeq: 2 INVITE<br>[May 13 08:21:59] Server: nexVortex SoupedUp Asterisk Hybrid<br>[May 13 08:21:59] Contact: <sip:<a href="http://192.168.134.227:57969" target="_blank">192.168.134.227:57969</a>><br>[May 13 08:21:59] Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER<br>[May 13 08:21:59] <span style="color:rgb(153,0,0)">Remote-Party-ID: "Steve" <<a href="mailto:sip%3A101@192.168.134.227" target="_blank">sip:101@192.168.134.227</a>>;priv<wbr>acy=off;screen=no</span><br>[May 13 08:21:59] Content-Length: 0<br><br><br></div><div>In this instance, it just looks like the rpid is a copy of the "From:" header. This isn't so interesting, as I already know my own name and extension number!<br><br></div><div>I traced this down to the add_rpid_header() func in the res/res_pjsip_caller_id module... but I suspect that the connected line updates play a role here, and I'm too much a nube to know where the "right" information is.<br></div><br><div>Am I hallucinating? Got a bad config? Or is there a bug here?<br></div></div></blockquote><div><br></div></div></div><div>There isn't much to determine why the wrong party information [1] is being used here.<br></div><div>I do think this is a configuration or dialplan issue and not a bug. Maybe you are using<br>CALLERID when you should be using CONNECTEDLINE on the PJSIP channel?<br></div><div><br></div><div>This could be a configuration issue caused by the difference between how chan_sip<br>and chan_pjsip do things. Since chan_sip predates pre-dial handlers you had to setup<br>information in inheritable channel variables and the SipAddHeader application before<br>dialing the destination so the outgoing channel gets created with expected information.<br>For PJSIP channels you need to use pre-dial handlers [2] to setup information on the<br>actual outgoing channel before the call gets placed.<br></div><div><br></div><div>Richard<br></div><div><br>[1] <a href="https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information" target="_blank">https://wiki.asterisk.org/<wbr>wiki/display/AST/Manipulating+<wbr>Party+ID+Information</a><br>[2] <a href="https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers" target="_blank">https://wiki.asterisk.org/<wbr>wiki/display/AST/Pre-Dial+<wbr>Handlers</a><br>[3] <a href="http://blogs.asterisk.org/2017/03/29/dialplan-handler-routines-allow-customization/" target="_blank">http://blogs.asterisk.org/<wbr>2017/03/29/dialplan-handler-<wbr>routines-allow-customization/</a><br><br></div></div></div></div>
<br>--<br>
______________________________<wbr>______________________________<wbr>_________<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/<wbr>mailman/listinfo/asterisk-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Steve Murphy<br>ParseTree Corporation<br>57 Lane 17<br>Cody, WY 82414<br>✉ murf at parsetree dot com<br>☎ 307-899-0510</div></div></div></div></div></div></div></div>
</div>