dear kamilio developers :
i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now，so that the kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request.
thanks
Hello,
On 7/11/12 4:23 AM, mike wrote:
dear kamilio developers :
i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now，so that the kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request.
sip.instance and reg-id are handled by the registrar/usrloc modules. Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module.
Cheers, Daniel
11 jul 2012 kl. 09:00 skrev Daniel-Constantin Mierla:
Hello,
On 7/11/12 4:23 AM, mike wrote:
dear kamilio developers :
i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now，so that the kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request.
sip.instance and reg-id are handled by the registrar/usrloc modules. Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module.
How do you recognize the flows and switch between them in case of failure?
/O
On 7/11/12 9:28 AM, Olle E. Johansson wrote:
11 jul 2012 kl. 09:00 skrev Daniel-Constantin Mierla:
Hello,
On 7/11/12 4:23 AM, mike wrote:
dear kamilio developers :
i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now，so that the kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request.
sip.instance and reg-id are handled by the registrar/usrloc modules. Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module.
How do you recognize the flows and switch between them in case of failure?
the flow switching part is not implemented in the module. the sip.instance and reg-id are used to update the location record. Haven't looked at it, but it might be possible to do the switching via config operations.
Cheerss, Daniel
11 jul 2012 kl. 15:16 skrev Daniel-Constantin Mierla:
On 7/11/12 9:28 AM, Olle E. Johansson wrote:
11 jul 2012 kl. 09:00 skrev Daniel-Constantin Mierla:
Hello,
On 7/11/12 4:23 AM, mike wrote:
dear kamilio developers :
i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now，so that the kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request.
sip.instance and reg-id are handled by the registrar/usrloc modules. Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module.
How do you recognize the flows and switch between them in case of failure?
the flow switching part is not implemented in the module. the sip.instance and reg-id are used to update the location record. Haven't looked at it, but it might be possible to do the switching via config operations.
Cool.
There has to be a way to easily handle two registrations with the same instance.ID as one contact in all operations in regards to lookup() and forking.
You want to know that you have more than one flow for the same contact (i.e. the same device). And possibly which flow (which ingres proxy) that is currently active.
/O
The other thing to consider within the "flow switching part" is the ability to "provide a limited version of a STUN server on the same interface and UDP port" as SIP.
That sounds like heavy going. Would it be doable within Kamailio?
I think this is a great RFC so would be happy to help with testing. I am working with a handset manufacturer to implement this now and they have caught up Kamailio on reg-id / sip.instance and are now looking for an SBC with which to test the flow-switching part.
Wondering if a bounty would help?
On 11 July 2012 14:21, Olle E. Johansson oej@edvina.net wrote:
11 jul 2012 kl. 15:16 skrev Daniel-Constantin Mierla:
On 7/11/12 9:28 AM, Olle E. Johansson wrote:
11 jul 2012 kl. 09:00 skrev Daniel-Constantin Mierla:
Hello,
On 7/11/12 4:23 AM, mike wrote:
dear kamilio developers :
i read the kamilio 3.3.0' s new features , it say it support outbound
, and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now，so that the
kamilio can be used as a edge proxy . i ask why because i can't find
where kamilio add flow-token and path for the register request.
sip.instance and reg-id are handled by the registrar/usrloc modules.
Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module.
How do you recognize the flows and switch between them in case of
failure?
the flow switching part is not implemented in the module. the
sip.instance and reg-id are used to update the location record. Haven't looked at it, but it might be possible to do the switching via config operations. Cool.
There has to be a way to easily handle two registrations with the same instance.ID as one contact in all operations in regards to lookup() and forking.
You want to know that you have more than one flow for the same contact (i.e. the same device). And possibly which flow (which ingres proxy) that is currently active.
/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
Hello,
On 9/10/12 3:52 PM, Richard Brady wrote:
The other thing to consider within the "flow switching part" is the ability to "provide a limited version of a STUN server on the same interface and UDP port" as SIP.
this is implemented (or at least partial) - I had no chance to look better at it to know exactly how far it is, being developed during SER times. See the files ser_stun.{c,h} in the core.
Cheers, Daniel
That sounds like heavy going. Would it be doable within Kamailio?
I think this is a great RFC so would be happy to help with testing. I am working with a handset manufacturer to implement this now and they have caught up Kamailio on reg-id / sip.instance and are now looking for an SBC with which to test the flow-switching part.
Wondering if a bounty would help?
On 11 July 2012 14:21, Olle E. Johansson <oej@edvina.net mailto:oej@edvina.net> wrote:
11 jul 2012 kl. 15:16 skrev Daniel-Constantin Mierla: > > On 7/11/12 9:28 AM, Olle E. Johansson wrote: >> 11 jul 2012 kl. 09:00 skrev Daniel-Constantin Mierla: >> >>> Hello, >>> >>> On 7/11/12 4:23 AM, mike wrote: >>>> dear kamilio developers : >>>> >>>> i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now,so that the >>>> kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request. >>> sip.instance and reg-id are handled by the registrar/usrloc modules. Path has to be added by intermediary proxies and it is also handled by registrar module. If the intermediary proxies are kamailio, then adding path is possible via path module. >> How do you recognize the flows and switch between them in case of failure? > the flow switching part is not implemented in the module. the sip.instance and reg-id are used to update the location record. Haven't looked at it, but it might be possible to do the switching via config operations. Cool. There has to be a way to easily handle two registrations with the same instance.ID as one contact in all operations in regards to lookup() and forking. You want to know that you have more than one flow for the same contact (i.e. the same device). And possibly which flow (which ingres proxy) that is currently active. /O _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto: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
On 25.09.2012 10:16, Daniel-Constantin Mierla wrote:
Hello,
On 9/10/12 3:52 PM, Richard Brady wrote:
The other thing to consider within the "flow switching part" is the ability to "provide a limited version of a STUN server on the same interface and UDP port" as SIP.
this is implemented (or at least partial) - I had no chance to look better at it to know exactly how far it is, being developed during SER times. See the files ser_stun.{c,h} in the core.
Hi Richard! If you want to test it, make sure to enable the code with STUN=1 while building.
regards Klaus
Hi Daniel, Peter, Klaus.
Sorry for delay I accidentally muted this thread :(
Thanks for the advice and great to hear it is being worked on. I will keep you updated on our testing.
Richard
On 25 September 2012 11:52, Klaus Darilion klaus.mailinglists@pernau.atwrote:
On 25.09.2012 10:16, Daniel-Constantin Mierla wrote:
Hello,
On 9/10/12 3:52 PM, Richard Brady wrote:
The other thing to consider within the "flow switching part" is the ability to "provide a limited version of a STUN server on the same interface and UDP port" as SIP.
this is implemented (or at least partial) - I had no chance to look better at it to know exactly how far it is, being developed during SER times. See the files ser_stun.{c,h} in the core.
Hi Richard! If you want to test it, make sure to enable the code with STUN=1 while building.
regards Klaus
______________________________**_________________ 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-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Klaus Darilion -
mike -
Olle E. Johansson -
Richard Brady