Been using Dial(${PJSIP_DIAL_CONTACTS(${EXTEN})}) for a while and it worked ok but today we started testing a new softphone. When you call this softphone using the above command, it rings busy and you get an error in the cli
[Aug 24 18:03:48] WARNING[311402][C-00000015]: app_dial.c:2635 dial_exec_full: Dial argument takes format (technology/resource)
OK… so I thought the registry contact was messed up… but then you change it to just dial direct.
Dial(PJSIP/${EXTEN})… the softphone gets the call with no errors.
Can this be a bug ?
This is what the softphone register looks like.
PJSIP/2018514204/sip:2018514204@98.109.129.48:56278;pn-prid=D4B72776C3C21FBE15B6BE3EC4EBC882CB58A4D1068D8C2CA928D63826657726:voip&6315695C0B9022F9517ED404D6722B670E590DC5D7339328E07D43233035479B:remote;pn-provider=apns;pn-param=ABCD1234.com.xbabble.sipphone.voip&remote;pn-silent=1;pn-timeout=0;pn-msg-str=IM_MSG;pn-call-str=IC_MSG;pn-groupchat-str=GC_MSG;pn-call-snd=notes_of_the_optimistic.caf;pn-msg-snd=msg.caf
What you see in that string, is push notification settings. I assume you’re testing the softphone (XBABBLE) on an iPhone.
If you have not setup Asterisk for push notifications (Which is not built in, as far as I’m aware), you can just disable push notifications in the app, and all that extra info, should disappear automatically.
Guys,
Keep in mind that this was working on the old xbabble, the new one just has an updated linphone sdk.
Why would asterisk work ok with a direct dial but not using PJSIP_DIAL_CONTACTS.
Also is there any other way to pull out all the contacts for a user and then just dial them direct ?
Or clean up the string so asterisk likes it.
Because dial strings are not a single technology/resource string, but multiple such strings, with &s between them. The URI you are getting back from dial contacts includes &s, so it looks like the following technology/resource strings:
I would agree but in my testing I am only registering 1 device and only see one contact. If that was the issue, a single device should work and it should fail only when more then one contact.
I don’t think what you’re doing is a viable solution. It may work now, but it’s very fragile, and can easily break.
It’s working on accident, not by design.
Also should you encounter a softphone where the string ends in voip, multiple contacts will break as they are joined with &. Meaning if my softphone registers a contact like sip:12345@domain.voip and has two registrations, the output from PJSIP_DIAL_CONTACTS will be sip:12345@domain.voip&sip:12345@domain1.voip and your workaround will completely break the dial contacts, preventing me from getting any calls at all, as what you send to dial will be sip:12345@domain.voipsip:12345@domain1.voip
The above example may to TOO simplified as you always have a port on your contacts, but the point is, it make work in your very specific situation, but it will not be possible to use it as a more generalized solution, especially not if you can’t control the clients your users use.
Your right it is a poor work around but I consider this a bug in asterisk and unless its fixed in the code I dont see any other way to get this to work without writing alternative script to do contact lookups.
Since I am only using our xbabble, this will work for us until we find another solution.
Were testing opensips in front of asterisk right now.
As far as I can tell, from reading RFCs (Unless there’s something I misunderstand) it might as well be a bug in the softphone. The pn-prid parameter, is intended to contain the push ID for the push service used, from what I can see, it seems that the softphone you’re using, tries to encode 2 different prid’s in the same parameter, which is not what the RFC describes.
The better solution would be, unless you specifically setup Asterisk in a way that actually handles push notifications, to just disable push notifications in the setup of the softphone, which should make those parameters go away.
Also I’ve experienced problems with too long contact headers not working, in the past. I do not remember, however, if the problem was with Asterisk or Kamailio, but I do remember it being Linphones contact headers that were to long, and got truncated. If you’re not using push, this is a non-issue, if you intend to use push, make sure the entire contact header is actually received.