Review Board 1.7.16


MWI Message-Account URI does not contain port/transport

Review Request #288 - Created June 22, 2009 and submitted

David Vossel
14659
Reviewers
asterisk-dev
Asterisk
The Message-Account field in a SIP MWI NOTIFY message is used to identify the account the MWI is for.  With some endpoints (SNOM Phones in particular) this field apparently needs to be a reachable URI.  This patch adds the port number and transport type fields to the URI so non-standard ports/transports can be reached correctly. 

I looked through RFC-3842 and did not see any evidence of Message-Account being used for anything other than account identification.  Even though it may be unnecessary in most cases, I don't see how adding the port and transport fields to the URI could cause any problems.

RFC-3842
" If the Request-URI or To header in a message-summary subscription
   corresponds to a group or collection of individual messaging
   accounts, the notifier MUST specify to which account the message-
   summary body corresponds.  Note that the account URI MUST NOT be
   delimited with angle brackets ("<" and ">").

      Message-Account: sip:alice@example.com"
klaus3000 initially reported this and include a patch for 1.4 which I believe was tested with a SNOM phone.  My patch is similar only it includes the transport type as well.

Diff revision 1 (Latest)

  1. /trunk/channels/chan_sip.c: Loading...
/trunk/channels/chan_sip.c
Revision 202357 New Change
[20] 11041 lines
[+20] [+] static int transmit_state_notify(struct sip_pvt *p, int state, int full, int timeout)
11042
 */
11042
 */
11043
static int transmit_notify_with_mwi(struct sip_pvt *p, int newmsgs, int oldmsgs, const char *vmexten)
11043
static int transmit_notify_with_mwi(struct sip_pvt *p, int newmsgs, int oldmsgs, const char *vmexten)
11044
{
11044
{
11045
	struct sip_request req;
11045
	struct sip_request req;
11046
	struct ast_str *out = ast_str_alloca(500);
11046
	struct ast_str *out = ast_str_alloca(500);
11047
	
11047
	int ourport;

    
   
11048
	const char *exten = S_OR(vmexten, default_vmexten);
11048
	initreqprep(&req, p, SIP_NOTIFY);
11049
	initreqprep(&req, p, SIP_NOTIFY);
11049
	add_header(&req, "Event", "message-summary");
11050
	add_header(&req, "Event", "message-summary");
11050
	add_header(&req, "Content-Type", default_notifymime);
11051
	add_header(&req, "Content-Type", default_notifymime);
11051

    
   
11052

   

    
   
11053
	ourport = ntohs(p->ourip.sin_port);
11052
	ast_str_append(&out, 0, "Messages-Waiting: %s\r\n", newmsgs ? "yes" : "no");
11054
	ast_str_append(&out, 0, "Messages-Waiting: %s\r\n", newmsgs ? "yes" : "no");
11053
	ast_str_append(&out, 0, "Message-Account: sip:%s@%s\r\n",
11055
	if (!ast_strlen_zero(p->fromdomain)) {
11054
		S_OR(vmexten, default_vmexten), S_OR(p->fromdomain, ast_inet_ntoa(p->ourip.sin_addr)));
11056
		ast_str_append(&out, 0, "Message-Account: sip:%s@%s\r\n", exten, p->fromdomain);

    
   
11057
	} else if (!sip_standard_port(p->socket.type, ourport)) {

    
   
11058
		if (p->socket.type == SIP_TRANSPORT_UDP) {

    
   
11059
			ast_str_append(&out, 0, "Message-Account: sip:%s@%s:%d\r\n", exten, ast_inet_ntoa(p->ourip.sin_addr), ourport);

    
   
11060
		} else {

    
   
11061
			ast_str_append(&out, 0, "Message-Account: sip:%s@%s:%d;transport=%s\r\n", exten, ast_inet_ntoa(p->ourip.sin_addr), ourport, get_transport(p->socket.type));

    
   
11062
		}

    
   
11063
	} else {

    
   
11064
		if (p->socket.type == SIP_TRANSPORT_UDP) {

    
   
11065
			ast_str_append(&out, 0, "Message-Account: sip:%s@%s\r\n", exten, ast_inet_ntoa(p->ourip.sin_addr));

    
   
11066
		} else {

    
   
11067
			ast_str_append(&out, 0, "Message-Account: sip:%s@%s;transport=%s\r\n", exten, ast_inet_ntoa(p->ourip.sin_addr), get_transport(p->socket.type));

    
   
11068
		}

    
   
11069
	}
11055
	/* Cisco has a bug in the SIP stack where it can't accept the
11070
	/* Cisco has a bug in the SIP stack where it can't accept the
11056
		(0/0) notification. This can temporarily be disabled in
11071
		(0/0) notification. This can temporarily be disabled in
11057
		sip.conf with the "buggymwi" option */
11072
		sip.conf with the "buggymwi" option */
11058
	ast_str_append(&out, 0, "Voice-Message: %d/%d%s\r\n",
11073
	ast_str_append(&out, 0, "Voice-Message: %d/%d%s\r\n",
11059
		newmsgs, oldmsgs, (ast_test_flag(&p->flags[1], SIP_PAGE2_BUGGY_MWI) ? "" : " (0/0)"));
11074
		newmsgs, oldmsgs, (ast_test_flag(&p->flags[1], SIP_PAGE2_BUGGY_MWI) ? "" : " (0/0)"));
[+20] [20] 6 lines
[+20] static int transmit_notify_with_mwi(struct sip_pvt *p, int newmsgs, int oldmsgs, const char *vmexten)
11066
	}
11081
	}
11067

    
   
11082

   
11068
	add_header_contentLength(&req, out->used);
11083
	add_header_contentLength(&req, out->used);
11069
	add_line(&req, out->str);
11084
	add_line(&req, out->str);
11070

    
   
11085

   
11071
	if (!p->initreq.headers) 
11086
	if (!p->initreq.headers)
11072
		initialize_initreq(p, &req);
11087
		initialize_initreq(p, &req);
11073
	return send_request(p, &req, XMIT_RELIABLE, p->ocseq);
11088
	return send_request(p, &req, XMIT_RELIABLE, p->ocseq);
11074
}
11089
}
11075

    
   
11090

   
11076
/*! \brief Notify a transferring party of the status of transfer (RFC3515) */
11091
/*! \brief Notify a transferring party of the status of transfer (RFC3515) */
[+20] [20] 14959 lines
  1. /trunk/channels/chan_sip.c: Loading...

https://reviewboard.asterisk.org/ runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to asteriskteam@digium.com.