Re: [SR-Users] Attended transfer in load-balanced multi-server setup
2011/4/13 Pan B. Christensen : > Scenarios: > A call comes in from Nortel/PSTN (user A) through Nortel1 to a SIP device > (user B). User B pushes the transfer button (puts current call on hold and > makes a new call) and dials a Nortel / PSTN number to user C. This call goes > out through the nortel2 server. Users B and C talk a short while before user > B pushes the Transfer button again to connect users A and C. In this > scenario, the REFER is forwarded by kamailio to nortel1, which replies > "SIP/2.0 481 Call leg/transaction does not exist." The call to join is of > course on the other asterisk (nortel2). The problem here is just in Nortel 1. It receives an in-dialog REFER through the dialog between user A and B, and such dialog contains a "replaces" parameter so user B can generate an INVITE with "Replaces" header to user C and the attended transfer completes. But for this to work you should use a single Nortel instance rather than two or more (I assume that the Nortel behaves as a PBX). The REFER Nortel (User 1) receives indicates it to call to another PSTN number, so it would generate a new call to the PSTN (rather than routing such an INVITE to the other Nortel box). It's not possible your scenario. It's certainly hard to balance traffic when you need a PBX role. > A similar scenario is where user B transfers to another SIP user. This call > will only exist in one of the kamailio servers, and Asterisk will give the > same response to the REFER. > > A third scenario is where both calls are handled by the same Asterisk > server. This scenario works. > > I'm assuming I'll have to build REFER-handling logic into kamailio, but am > unsure of how to proceed. Any suggestions? No, Kamailio can do nothing here. REFER is just an in-dialog request Kamailio correctly routes in the loose_route section. The problem is not the proxy, the problem is the explained above. Regards. -- Iñaki Baz Castillo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] loose_route security
2011/4/11 Daniel-Constantin Mierla : > first, skipping authentication for within dialog requests in default > configuration file comes mainly from the early years when not many sip > endpoints supported that. But can be done, of course and perhaps it should > be enabled (or at least added as a #!define option) I don't think that is a good option. It would break lot of scenarios: - An incoming INVITEl with RURI sip:al...@domain.org and To URI sip:2...@domain.org arrives to Kamailio which does lookup and routes the call to alice. - The call is established. - Later alice sends a REFER or a re-INVITE. Note that the request would contain "From: sip:2...@domain.org" (even if the AoR of alice us "sip:al...@domain.org". This is because From/To URI are usually unchanged whithin a dialog. - Kamailio ask for authentication to such REFER or re-INVITE. - alice's device adds "Proxy-Authorization: Digest username="alice", .". - If Kamailio does "check_from" the request would be rejected (as "alice" doesn't match "200"). -- Iñaki Baz Castillo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
2011/4/15 Klaus Darilion : > Support for various items in the proxy/registrars: > 50% path > 50% outbound > 33% sip/stun multiplexing > 20% diversion > 18% gruu > 17% history-info > 17% service-route Correct me if I'm wrong: Items implemented in Kamailio/sip-router: - path - diversion -- Iñaki Baz Castillo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] loose_route security
Iñaki Baz Castillo writes: > - Later alice sends a REFER or a re-INVITE. Note that the request > would contain "From: sip:2...@domain.org" (even if the AoR of alice us > "sip:al...@domain.org". This is because From/To URI are usually > unchanged whithin a dialog. inaki, refer would contain header Referred-By: sip:al...@domain.org which k would use for Proxy-Authorization. -- juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
16 apr 2011 kl. 15.59 skrev Iñaki Baz Castillo: > 2011/4/15 Klaus Darilion : >> Support for various items in the proxy/registrars: >> 50% path >> 50% outbound >> 33% sip/stun multiplexing >> 20% diversion >> 18% gruu >> 17% history-info >> 17% service-route > > Correct me if I'm wrong: > > Items implemented in Kamailio/sip-router: > - path > - diversion > Yes, Kamailio is behind and after focusing so much on the merger of the code I think it would be good to plan some new features for a coming release. The issue is what of all the new SIP features we need. History-info seems useful for Asterisk, don't know how much it will affect Kamailio. Gruu, well. I haven't seen many implementations out there. I can theoretically see a need for it both in NAT situations and IPv6. Diversion is deprecated. Outbound is the final NAT traversal solution - which seems to be getting a lot of traction. Remember that there was very few participants in this SIPit so 50% is not a "market share" - far from it. /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
2011/4/16 Olle E. Johansson : > Yes, Kamailio is behind and after focusing so much on the merger of the code > I think it would be good to plan some new features for a coming release. The > issue is what of all the new SIP features we need. > History-info seems useful for Asterisk, don't know how much it will affect > Kamailio. > Gruu, well. I haven't seen many implementations out there. If the registrar doesn't support GRUU then it doesn't matter whether clients support it or not :) I think GRUU can be really useful. > I can theoretically see a need for it both in NAT situations and IPv6. > Diversion is deprecated. No, it became RFC 5806 past year: http://tools.ietf.org/html/rfc5806 > Outbound is the final NAT traversal solution - which seems to be getting a > lot of traction. Remember that there was very few participants in this SIPit > so 50% is not a "market share" - far from it. -- Iñaki Baz Castillo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
2011/4/16 Iñaki Baz Castillo : >> Diversion is deprecated. > > No, it became RFC 5806 past year: > > http://tools.ietf.org/html/rfc5806 But it has "Category: Historic". -- Iñaki Baz Castillo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
Iñaki Baz Castillo writes: > > No, it became RFC 5806 past year: > > > > http://tools.ietf.org/html/rfc5806 > > But it has "Category: Historic". they could not make it anything else because official solution is history-info that almost no one has implemented. -- juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
On 4/16/11 7:30 PM, Olle E. Johansson wrote:
16 apr 2011 kl. 15.59 skrev Iñaki Baz Castillo:
2011/4/15 Klaus Darilion:
Support for various items in the proxy/registrars:
50% path
50% outbound
33% sip/stun multiplexing
20% diversion
18% gruu
17% history-info
17% service-route
Correct me if I'm wrong:
Items implemented in Kamailio/sip-router:
- path
- diversion
Yes, Kamailio is behind and after focusing so much on the merger of the code I
think it would be good to plan some new features for a coming release.
I think this statement is not true. While a lot of work was indeed done
on merging code, there were a lot of new featured added, much more than
we had we previous major releases, many based on standardizations (e.g.,
presence extensions to conference, dialog info, xcap, a.s.o).
The the core supports processing stun, see ser_stun.{c,h} - the guys at
ser added that very long time ago.
As for next release, there are lot of features added
(http://sip-router.org/wiki/features/new-in-devel), more to come, but I
think most of developers here got tired hunting the ghosts of IETF specs
that never were any useful nor had a touch with the reality.
As of myself, I really work now on what is demanded, there is no time to
jump and implement any rfc/draft published based on theories elaborated
by guys that never implemented their specs. Moreover, some of them are
now in different boat and make "incredible" statements about sip
considering their role in the past with this protocol...
Cheers,
Daniel
The issue is what of all the new SIP features we need. History-info seems useful for
Asterisk, don't know how much it will affect Kamailio. Gruu, well. I haven't seen many
implementations out there. I can theoretically see a need for it both in NAT situations
and IPv6. Diversion is deprecated. Outbound is the final NAT traversal solution - which
seems to be getting a lot of traction. Remember that there was very few participants in
this SIPit so 50% is not a "market share" - far from it.
/O
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
I wholeheartedly agree with Daniel's assessment. 3.x and 3.1.x have seen
incredibly important feature gains that have been revolutionary for our work.
It is true that a lot of the feature growth has been in internal/runtime
capabilities of Kamailio as a pseudoprogrammatic execution environment, but so
what? The net benefit to implementors and users of features like configuration
file splitting, new TM, rtimer, mqueue, HTTP server + XMLRPC, and many other
things has been enormous.
Also, I strongly agree that the focus of the project should not be to go around
chasing someone's novel, indecipherable IETF draft of the hour. They come and
go like influenza. Note how many expired drafts were adopted by the market de
facto immortally despite their expiration, like RPID, or, more often,
completely ignored despite persistent attempts at standardisation. As Daniel
said, no relation to reality in a lot of them. It becomes clear over a much
longer period what should ultimately be supported, and watching the standards
track is not a practical way to try to make that determination.
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
On Apr 16, 2011, at 2:27 PM, Daniel-Constantin Mierla wrote:
>
>
> On 4/16/11 7:30 PM, Olle E. Johansson wrote:
>> 16 apr 2011 kl. 15.59 skrev Iñaki Baz Castillo:
>>
>>> 2011/4/15 Klaus Darilion:
Support for various items in the proxy/registrars:
50% path
50% outbound
33% sip/stun multiplexing
20% diversion
18% gruu
17% history-info
17% service-route
>>> Correct me if I'm wrong:
>>>
>>> Items implemented in Kamailio/sip-router:
>>> - path
>>> - diversion
>>>
>> Yes, Kamailio is behind and after focusing so much on the merger of the code
>> I think it would be good to plan some new features for a coming release.
> I think this statement is not true. While a lot of work was indeed done on
> merging code, there were a lot of new featured added, much more than we had
> we previous major releases, many based on standardizations (e.g., presence
> extensions to conference, dialog info, xcap, a.s.o).
>
> The the core supports processing stun, see ser_stun.{c,h} - the guys at ser
> added that very long time ago.
>
> As for next release, there are lot of features added
> (http://sip-router.org/wiki/features/new-in-devel), more to come, but I think
> most of developers here got tired hunting the ghosts of IETF specs that never
> were any useful nor had a touch with the reality.
>
> As of myself, I really work now on what is demanded, there is no time to jump
> and implement any rfc/draft published based on theories elaborated by guys
> that never implemented their specs. Moreover, some of them are now in
> different boat and make "incredible" statements about sip considering their
> role in the past with this protocol...
>
> Cheers,
> Daniel
>
>> The issue is what of all the new SIP features we need. History-info seems
>> useful for Asterisk, don't know how much it will affect Kamailio. Gruu,
>> well. I haven't seen many implementations out there. I can theoretically see
>> a need for it both in NAT situations and IPv6. Diversion is deprecated.
>> Outbound is the final NAT traversal solution - which seems to be getting a
>> lot of traction. Remember that there was very few participants in this SIPit
>> so 50% is not a "market share" - far from it.
>>
>> /O
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
2011/4/16 Daniel-Constantin Mierla : > As for next release, there are lot of features added > (http://sip-router.org/wiki/features/new-in-devel), more to come, but I > think most of developers here got tired hunting the ghosts of IETF specs > that never were any useful nor had a touch with the reality. > > As of myself, I really work now on what is demanded, there is no time to > jump and implement any rfc/draft published based on theories elaborated by > guys that never implemented their specs. Moreover, some of them are now in > different boat and make "incredible" statements about sip considering their > role in the past with this protocol... Hi Daniel, I strongly agree with you (and sure you know I'm a good "friend" of IETF-way= :) I just said that, IMHO, gruu and tcp-outbound are two cool features. Of course, both need implementation in client and server side. The fact that there are not gruu implementations yet doesn't mean that the feature is interesting. Cheers. -- Iñaki Baz Castillo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Diversion header
> > > >> I can theoretically see a need for it both in NAT situations and IPv6. > >> Diversion is deprecated. > > No, it became RFC 5806 past year: > > http://tools.ietf.org/html/rfc5806 Category: HIstoric Because it took so much time between the Diversion draft and the SIP-history RFC, everyone implemented Diversion headers. The IETF felt that this had to be documented, but not on standard trac and not as any sort of recommendation. Result: It's still deprecated. Not all RFCs are standard trac. The IAX2 and ZRTP are just informational RFCs even though some people claim that these protocols are now "IETF standard" since they have RFC numbers... Well, they're not. We could propably write an RFC about Kamailio's MI interface or the RTPproxy management protocol and publish, but they won't be on standard track... /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
16 apr 2011 kl. 19.36 skrev Iñaki Baz Castillo: > 2011/4/16 Olle E. Johansson : >> Yes, Kamailio is behind and after focusing so much on the merger of the code >> I think it would be good to plan some new features for a coming release. The >> issue is what of all the new SIP features we need. > >> History-info seems useful for Asterisk, don't know how much it will affect >> Kamailio. > >> Gruu, well. I haven't seen many implementations out there. > > If the registrar doesn't support GRUU then it doesn't matter whether > clients support it or not :) > I think GRUU can be really useful. Me too. So maybe that's a good start. /O ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Fwd: [RAI] SIPit 28 summary
16 apr 2011 kl. 20.27 skrev Daniel-Constantin Mierla:
>
>
> On 4/16/11 7:30 PM, Olle E. Johansson wrote:
>> 16 apr 2011 kl. 15.59 skrev Iñaki Baz Castillo:
>>
>>> 2011/4/15 Klaus Darilion:
Support for various items in the proxy/registrars:
50% path
50% outbound
33% sip/stun multiplexing
20% diversion
18% gruu
17% history-info
17% service-route
>>> Correct me if I'm wrong:
>>>
>>> Items implemented in Kamailio/sip-router:
>>> - path
>>> - diversion
>>>
>> Yes, Kamailio is behind and after focusing so much on the merger of the code
>> I think it would be good to plan some new features for a coming release.
> I think this statement is not true. While a lot of work was indeed done on
> merging code, there were a lot of new featured added, much more than we had
> we previous major releases, many based on standardizations (e.g., presence
> extensions to conference, dialog info, xcap, a.s.o).
>
> The the core supports processing stun, see ser_stun.{c,h} - the guys at ser
> added that very long time ago.
>
> As for next release, there are lot of features added
> (http://sip-router.org/wiki/features/new-in-devel), more to come, but I think
> most of developers here got tired hunting the ghosts of IETF specs that never
> were any useful nor had a touch with the reality.
>
> As of myself, I really work now on what is demanded, there is no time to jump
> and implement any rfc/draft published based on theories elaborated by guys
> that never implemented their specs. Moreover, some of them are now in
> different boat and make "incredible" statements about sip considering their
> role in the past with this protocol...
That's good feedback. I meant that we're behind the IETF. But so are most
implementations out there...
Sorry if I upset anyone. That wasn't my intention.
/O
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
