A little FYI. The concept of an AOR having multiple contacts is not new. It’s been around since the start of SIP. As well, PJSIP is not new. It’s been around for some time as well. So the fact that Asterisk, in the last 5-6 years, has moved to support both of these things it seems new to you if Asterisk has been your only experience.
It would also be nice to know the source of your statement that headers get split when going over the public Internet when having “too many contacts” for PJSIP. Because that sounds more like a networking/router issue as it makes no sense that nothing bad happens locally but the moment it goes out a router to the Internet headers get split and this is a PJSIP/Asterisk problem.
I don’t recall saying that pjsip or supporting multiple contacts is new. Flowroute has been doing it since launch.
I didn’t say that this is “for PJSIP.” And your response suggests that you might not understand the relationship between pjsip, Chan_SIP, and SIP. Pjsip and Chan_SIP are the drivers used in Asterisk. SIP is the protocol that goes out over the internet.
Thus, the splitting effect is not “for PJSIP.” Rather, as I said in my post, “the SIP headers” will get split if they are too long and go out over the public internet. This could conceivably happen with Chan_SIP, but since Chan_SIP doesn’t support multiple contacts, nobody would ever try to use it that way.
My source for this tidbit was Flowroute technical support. Flowroute has supported multiple contacts since they launched. I’ve been using multiple FreePBX boxes to register to the same Flowroute trunks for years. I use Chan_SIP, since my boxes all only connect to one contact. But, Flowroute is using something else (probably FreeSWITCH) that supports multiple contacts. Flowroute did warn me that if you get above 3 contacts, you run the risk of having the packets split, and things breaking. I believe, but am not positive, that they told me that it has do with the SIP packets exceeding the MTU.
I think our OP can decide for himself whether my advice will work for him. And if you think otherwise, I think we would all appreciate it if you would tell us why.
No, you did not but in public conversations like this sometimes a reply to one persons comment isn’t a direct reply to that person but to everyone that is involved in the conversation. Some people have treated PJSIP like it is some new thing because it’s new to Asterisk. I was just laying out some general FYI.
Been doing it for over 15 years at every place I’ve been at.
Actually, I do hence my reply pointing out that it was a network/router issue and not a PJSIP/Asterisk issue. Because Chan_SIP and PJSIP generate different SIP headers and by that I mean the standard ones are there but PJSIP has other headers that Chan_SIP doesn’t. So that would mean a PJSIP packet would be larger than a Chan_SIP packet.
Flowroute would be wrong. Having more than three contacts is more common that some think and this would mean everyone is either an expert at making this magically work for more than 3 contacts or it just works as it is supposed to because it was designed that way.
Yes, that would be a valid reason as any packets that exceed the MTU would be split and since SIP is UDP and stateless it can be way less tolerable when this happens.
Sorry but so far all of this can be 100% related to routers poorly handling SIP and things like SIP ALG touching the packets, poorly configured networks/routers or poorly configured SIP systems.
As you said, they might be wrong. I can only report what they told me.
Then again, it may be that most people using pjsip with multiple extensions aren’t sending any packets out over the internet, where the MTU may be different than on their LAN. Or perhaps the pjsip team have come up with their own solution for that issue.
Various documentation such as RFCs, Asterisk (and other) blogs/wiki/samples, research, asking questions and, of course, actually using and testing things with PJSIP so I understood how it was being implemented in Asterisk.
May I suggest you rectify this shortcoming. Until you do, please preface all your recommendations against PJSIP with those words. PJSIP is the FreePBX/Asterisk standard now and that is not changing. Anyone setting up systems now should be using it.
My recommendation in this case is not “against PJSIP.” In fact, it has nothing to do with PJSIP. Both D&U Mode (which I have mentioned, but not recommended) and the “mailbox” field (which I did recommend) are independent of the SIP channel driver being used.
I acknowledge, however, that I have indicated in other threads that Chan_SIP is more mature and works without issue in my applications. As soon as it becomes evident that pjsip works as well as Chan_SIP, I’ll give it another try.
If you can provide a link to any of those, I would appreciate it. As Lorne suggested, Pjsip is the future of Asterisk, and I’d love to learn more about it.
Yes I’m sure you would but you can look at the SIP RFCs, you can look at the blogs over at asterisk.org, you can look at the wiki at wiki.asterisk.org and you can look at the samples in the repos over at github for Asterisk. You can also look at pjsip.org.
Again, PJSIP isn’t doing anything new and as I said most of what I need to see what how Asterisk implemented PJSIP. Everything else is over a decade and a half of learning and experience with SIP.
It appears that I misunderstood. You initially wrote that:
But, now you’re saying that:
Perhaps this is my lack of experience with pjsip, but it would seem that if pjsip is introducing new headers, that is something new. If pjsip is introducing entirely new headers, I don’t see that it would be referenced in the SIP RFCs. The RFCs are platform agnostic. Do you mean that pjsip supports new SIP headers that Chan_SIP didn’t support? If so, wouldn’t that break the interoperability that is the hallmark of SIP?
Anyways, if you run across specific links, I would appreciate it if you would PM me with them.
Yes, it is. In Asterisk Chan_SIP doesn’t send two session related headers. It also has less options in the Supported header.
The PJSIP stack has been around for a long time. Asterisk decided to go with that instead of Chan_SIP2 I guess. So in comparison to Chan_SIP, PJSIP is doing more than what Chan_SIP because it follows RFC standards such as AoRs, Contacts, etc. something Chan_SIP did not do very closely.
So when it comes to the standards of SIP, Chan_PJSIP is more aligned with them then Chan_SIP ever was in Asterisk. That is because PJSIP is an RFC compliant stack that has been used by many vendors. That said, Chan_PJSIP is Asterisk’s implementation of the PJSIP stack so it’s not a 100% “side by side”.
Yes, that is it. It’s not your lack of experience with (or knowledge of) Chan_PJSIP that meant you didn’t know SIP headers were generated more to standards or that Chan_PJSIP supports NAPTR lookups (Chan_SIP doesn’t) or that it has more improved SRV lookup handling. In that case Chan_SIP just gets the first returned SRV host which means it won’t look at any others so it treats an SRV lookup more like an A record lookup.
That would also mean that when you use Chan_SIP as your trunk to someone like Flowroute you do not get the benefits of their new failover POPs because those rely on SRV records for that to work.
My only inquiry was about your two apparently inconsistent statements. In one post, you said that pjsip adds new headers, and in another you said that pjsip did nothing new vis a vis chan_sip.
I initially wondered if my lack of knowledge was causing me to be unable to determine how those two statements could both be true at the same time. However, you have now confirmed that pjsip does do a bunch of new things (which is what I suspected).
