Hi, I’ve put responses to your issues below:
- In step 3 SUB (event: reg) has expires as 600000, the 200OK from CW responds with the same expiry timer. Is there a way I can change this expiry in 200OK to 43260? If yes, please let me know how I can modify: I’ve raised an issue to track making the maximum subscription length configurable (https://github.com/Metaswitch/sprout/issues/660). When this issue is merged, then there will be a configuration option sub_max_expires, which you can set in /etc/clearwater/config on the Sprout node. - In Step 5 the NOTIFY sent by CW doesn't carry the “Subscription-state” Header due to which a 400 rejection message is sent by the SIP client. Also the expiry =600, can this be modified to 3600? If yes, please let me know how I can modify The missing Subscription-State header has been fixed in issue https://github.com/Metaswitch/sprout/issues/505 - this fix is in the Jet Set Radio release. To change the session-expires in the Notify you can change the default_session_expires parameter. You can do this by adding/editing default_session_expires in /etc/clearwater/config on Sprout and restart Sprout (sudo monit restart sprout). This is a global change however, and will affect the length of every Session-Expires that Sprout adds. - Step7, SUB (event: message-summary) would be sent by the SIP client (this is as per PC 2.0 spec) and this is how it is happening, but CW is sending a SUB (event: message-summary) to the SIP client. This results in 489 Bad Event response by SIP client (for the one sent by CW) and by CW (for the one sent by SIP client) Clearwater only processes SUBSCRIBEs that have the Event type ‘reg’. If Clearwater receives a SUBSCRIBE with a different Event type it will simply proxy it on (note that Clearwater will route the SUBSCRIBE to an application server if the appropriate iFCS are set). - In Step1, currently it is a TN based registration (IMPI), is it possible to do a MAC (IMPU) based registration? If yes, please let me know how this can be achieved. I’m not sure what you mean by this. Can you link me to the relevant specs? Ellie From: Tek Gee [mailto:[email protected]] Sent: 10 July 2014 23:31 To: Eleanor Merry Cc: [email protected] Subject: Re: [Clearwater] SIP Client not able to register with CW due to different Contact header Hi Eleanor, The registration works with the new image, the SIP client accepts the 200OK received from the CW. I am facing issues with the subsequent SUBSCRIPTIONS & NOTIFYs, the expected flow for the client I am testing is: Device ----> CW 1. REG--------> 2. <----------401/200OK 3. SUB (event: reg)------> 4. <-----------200OK 5. <--------------Notify (event: reg) 6. 200OK -------> 7. SUB (event: message-summary) -------> 8. <----------------200OK 9. <--------------Notify (event: message-summary) 10. 200OK -------> The issue I need help with: * In step 3 SUB (event: reg) has expires as 600000, the 200OK from CW responds with the same expiry timer. Is there a way I can change this expiry in 200OK to 43260? If yes, please let me know how I can modify * In Step 5 the NOTIFY sent by CW doesn't carry the “Subscription-state” Header due to which a 400 rejection message is sent by the SIP client. Also the expiry =600, can this be modified to 3600? If yes, please let me know how I can modify * Step7, SUB (event: message-summary) would be sent by the SIP client (this is as per PC 2.0 spec) and this is how it is happening, but CW is sending a SUB (event: message-summary) to the SIP client. This results in 489 Bad Event response by SIP client (for the one sent by CW) and by CW (for the one sent by SIP client) * In Step1, currently it is a TN based registration (IMPI), is it possible to do a MAC (IMPU) based registration? If yes, please let me know how this can be achieved. Attached are the traces for the above mentioned issues. Thanks for the support. On Thu, Jul 10, 2014 at 10:14 AM, Tek Gee <[email protected]<mailto:[email protected]>> wrote: Hi Eleanor, Thanks for the quick response. I will try to download the latest version from https://github.com/Metaswitch/clearwater-docs/wiki/All-in-one%20OVF%20Installation Would this link have the image you mentioned "International Cricket Captain" ? Also, how can I check the version on the CW that I am currently running. Thanks On Thu, Jul 10, 2014 at 7:05 AM, Eleanor Merry <[email protected]<mailto:[email protected]>> wrote: Hi, Thanks for raising this! What version of Clearwater are you running? I ask because we've made some changes to this fairly recently to correctly parse the parameters in the Contact header (e.g. https://github.com/Metaswitch/sprout/commit/de7ec101c63280f4c231c4fec480274f8fcaa1c4). If you're not running the up-to-date version of Clearwater then can you upgrade and see if this issue persists. If you are running up-to-date Clearwater (the current version is International Cricket Captain) then can you give me more details as to the exact REGISTER scenario you're using, and attach the debug logs from Sprout so that I can try and reproduce the issue on my system. The sprout logs are produced in /var/log/sprout/sprout*.txt. By default the logging level is set to log level 2, which only includes errors and very high level events. To enable debug logs, change the log level to 5 by writing log_level=5 to /etc/clearwater/user_settings (creating it if it doesn't exist already), and restart sprout (using service sprout stop - monit automatically restarts it). Ellie -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Tek Gee Sent: 09 July 2014 22:34 To: [email protected]<mailto:[email protected]> Subject: [Clearwater] SIP Client not able to register with CW due to different Contact header Hi, Please could you help me with the below issue, the SIP client am using is not able to register with CW. Though the CW sends a 200OK to the register, the client doesn't accept it and keeps sending REGISTER as it doesnt like the 200OK it received. The reason I got from the SIP client developers was " The problem is most likely that the server adds the transport=udp in the wrong place in the contact. It should remain a URI parameter." [2013/12/10 16:54:21] Dec 10 16:52:12.810 6.4.20.162:5060<http://6.4.20.162:5060>>>>> Send to 6.4.71.86:8060<http://6.4.71.86:8060> [2013/12/10 16:54:21] REGISTER sip:example.com<http://example.com> SIP/2.0 [2013/12/10 16:54:21] Accept: application/reginfo+xml, application/rlmi+xml, application/sdp, application/simple-message-summary, application/watcherinfo+xml, message/sipfrag, multipart/mixed [2013/12/10 16:54:21] Via: SIP/2.0/UDP 6.4.20.162:5060<http://6.4.20.162:5060> ;branch=z9hG4bK60b1c87c1fb06a89f;rport [2013/12/10 16:54:21] Route: <sip:6.4.71.86:8060;lr> [2013/12/10 16:54:21] Max-Forwards: 70 [2013/12/10 16:54:21] From: <sip:[email protected]<mailto:sip%[email protected]>>;tag=7a1d1acc78 [2013/12/10 16:54:21] To: <sip:[email protected]<mailto:sip%[email protected]>> [2013/12/10 16:54:21] Call-ID: 24cc062b641c4110 [2013/12/10 16:54:21] CSeq: 1186841651 REGISTER [2013/12/10 16:54:21] Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, PRACK, REFER, SUBSCRIBE, UPDATE [2013/12/10 16:54:21] Allow-Events: refer, vq-rtcpxr [2013/12/10 16:54:21] Authorization: Digest username="[email protected]<mailto:[email protected]> ",realm="example.com<http://example.com>",uri="sip:example.com<http://example.com> ",nonce="",response="",algorithm=MD5 [2013/12/10 16:54:21] Contact: *<sip:6505550319<tel:6505550319>@6.4.20.162:5060;transport=udp>* ;expires=3600;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-088039F7183D>" [2013/12/10 16:54:21] Supported: 100rel, answermode, eventlist, gruu, histinfo, outbound, path, replaces, tdialog, timer [2013/12/10 16:54:21] Content-Length: 0 [2013/12/10 16:54:21] [2013/12/10 16:54:21] Dec 10 16:52:12.840 6.4.20.162:5060<http://6.4.20.162:5060><<<< Recv from 6.4.71.86:8060<http://6.4.71.86:8060> [2013/12/10 16:54:21] SIP/2.0 200 OK [2013/12/10 16:54:21] Service-Route: <sip:10.0.2.15:5054<http://10.0.2.15:5054> ;transport=TCP;lr;orig> [2013/12/10 16:54:21] Via: SIP/2.0/UDP 6.4.20.162:5060<http://6.4.20.162:5060> ;rport=5060;received=10.0.2.2;branch=z9hG4bK60b1c87c1fb06a89f [2013/12/10 16:54:21] Call-ID: 24cc062b641c4110 [2013/12/10 16:54:21] From: <sip:[email protected]<mailto:sip%[email protected]>>;tag=7a1d1acc78 [2013/12/10 16:54:21] To: <sip:[email protected]<mailto:sip%[email protected]> >;tag=z9hG4bKPjB3CstzB2s3dJ001qhYwztgvKCqIcRiEE [2013/12/10 16:54:21] CSeq: 1186841651 REGISTER [2013/12/10 16:54:21] Supported: outbound [2013/12/10 16:54:21] *Contact: <sip:[email protected]:5060<http://sip:[email protected]:5060> <http://sip:[email protected]:5060>>*;expires=3600;*transport=udp* ;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-088039F7183D>" [2013/12/10 16:54:21] Require: outbound [2013/12/10 16:54:21] Path: sip:[email protected]:5058<http://sip:[email protected]:5058> ;transport=TCP;lr;ob [2013/12/10 16:54:21] P-Associated-URI: <sip:[email protected]<mailto:sip%[email protected]>> [2013/12/10 16:54:21] Content-Length: 0 Thanks _______________________________________________ Clearwater mailing list [email protected]<mailto:[email protected]> http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
